RE: [Haskell] Weird field name mangling.
[Redirecting to ghc-bugs]
That's a bug in 6.4.1 thank you. The reason has to do with z-encoding strings
in case they are output to C-land.
Happily the bug is not present in 6.6; I doubt we'll fix 6.4.1 now.
I've added a test to make sure it does not creep back: drvrun022
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arthur van
| Leeuwen
| Sent: 22 November 2006 16:59
| To: haskell@haskell.org
| Subject: [Haskell] Weird field name mangling.
|
| L.S.,
|
| consider the following code:
|
| module TestZ where
|
| import Data.Generics
|
| data TestZ = TestZ { testz :: Int }
|deriving (Show, Read, Eq, Typeable, Data)
|
| main = print $ constrFields . toConstr $ TestZ { testz = 2 }
|
| I would expect this to output [testz]. Instead it outputs [testzz],
| using GHCi 6.4.1. Why is that z doubled?
|
| Doei, Arthur.
|
| --
|
|/\/ | [EMAIL PROTECTED] | Work like you don't need
| the money
| /__\ / | A friend is someone with whom | Love like you have never
| been hurt
| /\/__ | you can dare to be yourself | Dance like there's nobody
| watching
|
|
|
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1006: 'impossible' happened in reportNoInstance?
#1006: 'impossible' happened in reportNoInstance? -+-- Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail171| Architecture: Unknown Os: Unknown | -+-- Changes (by simonpj): * resolution: = fixed * status: new = closed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1006 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4, ss_atJ is out of scope
#1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4, ss_atJ is out of scope +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler|Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by [EMAIL PROTECTED]): Looks like the same thing happens with nofib/real/fulsom/Csg.hs -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1023 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4, ss_atJ is out of scope
#1023: Core Lint Errors: in result of Simplifier phase 0, iteration 1 out of 4, ss_atJ is out of scope +--- Reporter: [EMAIL PROTECTED] | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler|Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by simonpj): Thanks. It's a bug in the simplifier, presumably following my recent upheaval. I'm looking into it. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1023 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X
#918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X ---+ Reporter: guest | Owner: thorkilnaur Type: task | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) |Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A| Architecture: Unknown Os: MacOS X| ---+ Changes (by thorkilnaur): * owner: = thorkilnaur -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/918 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Fix ghc-6.6 darcs-all for Mac OS X 10.4
Hello,
The following patch fixes ghc-6.6 darcs-all for Mac OS X 10.4.
Best regards
Thorkil
New patches:
[Fix darcs-all for Mac OS X
Thorkil Naur [EMAIL PROTECTED]**20061123125539
The regular exporession /\? which is used by darcs-all to stand for zero or one /'s
seems to be a GNU extension of basic regular expressions. In any case, it is not
supported by sed on Mac OS X 10.4.
The patched darcs-all works on Max OS X and (SuSE) Linux.
] {
hunk ./darcs-all 13
-default_extra_repo_root=`echo $default_repo_root | sed 's!/ghc-6.6/\?$!!'`
+default_extra_repo_root=`echo $default_repo_root | sed 's!/ghc-6.6/\{0,1\}$!!'`
}
Context:
[cas(): modify assembly syntax to make it work everywhere (hopefully)
Simon Marlow [EMAIL PROTECTED]**20061121132646]
[Fix printf$LDBLStub workaround for Darwin
[EMAIL PROTECTED]
Apparently, the original fix never really worked due to typos and oversights.
]
[Add ppr for the MKPAP case, and rearrange the other cases to match the datatype
Ian Lynagh [EMAIL PROTECTED]**20061120155352]
[Avoid problems with unaligned loads on alpha/mips/mipsel/arm
Ian Lynagh [EMAIL PROTECTED]**20061120154914
This is overly conservative, but it works.
]
[Add a C++ phase. Fixes bug #800
Lemmih [EMAIL PROTECTED]**20060727080023]
[Don't force -static on mips
Ian Lynagh [EMAIL PROTECTED]**20061120122305]
[MERGE: Don't make ghc threaded if GhcNotThreaded is YES
Ian Lynagh [EMAIL PROTECTED]**20061120121855]
[Cope with big endian float word order on little endian machines
Ian Lynagh [EMAIL PROTECTED]**20061120121309]
[Fix unregisterised alpha builds
Ian Lynagh [EMAIL PROTECTED]**20061004125857]
[use lock cmpxchg instead of lock/cmpxchg
Simon Marlow [EMAIL PROTECTED]**20061117114429
I'm not sure where the latter version came from, but it apparently
doesn't generate a legal instruction on Solaris.
]
[MERGE: Fix (yet another) odd interaction between selector thunks and compacting GC
Ian Lynagh [EMAIL PROTECTED]**20061115135020
Tue Nov 14 12:31:57 GMT 2006 Simon Marlow [EMAIL PROTECTED]
* Fix (yet another) odd interaction between selector thunks and compacting GC
This should fix errors of the form
internal error: scavenge_mark_stack: unimplemented/strange closure
type 28 @ 0x2b92e5f79960
But since it's quite difficult to reproduce the error, I can't be 100%
certain it's gone. I certainly can't reproduce it again after the
fix, anyway.
]
[Fix compilation problems
Ian Lynagh [EMAIL PROTECTED]**20061115015300]
[Default the kind of unconstrained meta-type variables before tcSimplifyTop
[EMAIL PROTECTED]
This patch fixes a long standing bug, Trac #179,
and a recently reported one, Trac #963.
The problem in both cases was an unconstrained type variable 'a', of kind
argTypeKind (printed ??) or openTypeKind (?). At top level we now default
the kind of such variables to liftedTypeKind (*). This is important because
then instance declarations can match it. The defaulting function is called
TcMType.zonkTopTyVar, and is commented. (Most of the extra lines in the
patch are comments!)
]
[MERGE: Fix error reporting for contexts during deriving (Trac 958)
Ian Lynagh [EMAIL PROTECTED]**20061115005551
[EMAIL PROTECTED]
When doing the fixpoint iteration for 'deriving' we have to be careful
not to end up in a loop, even if we have -fallow-undecidable-instances.
Test is tcfail169
]
[Improve error message (push to 6.6 branch)
[EMAIL PROTECTED]
[Improve handling of unused imports (test is mod75)
[EMAIL PROTECTED]
[Remove STANDALONE_PACKAGE bits that had escaped the removal
Ian Lynagh [EMAIL PROTECTED]**20061110182050]
[use the right $(HC) for stage 3
Simon Marlow [EMAIL PROTECTED]**20061109101753]
[remove unused STANDALONE_PACKAGE stuff
Simon Marlow [EMAIL PROTECTED]**20061109101729]
[Do not filter the type envt after each GHCi stmt
[EMAIL PROTECTED]
Fixes Trac #925
A new comment in TcRnDriver in tcRnStmt reads thus:
At one stage I removed any shadowed bindings from the type_env;
they are inaccessible but might, I suppose, cause a space leak if we leave them there.
However, with Template Haskell they aren't necessarily inaccessible. Consider this
GHCi session
Prelude let f n = n * 2 :: Int
Prelude fName - runQ [| f |]
Prelude $(return $ AppE fName (LitE (IntegerL 7)))
14
Prelude let f n = n * 3 :: Int
Prelude $(return $ AppE fName (LitE (IntegerL 7)))
In the last line we use 'fName', which resolves to the *first* 'f'
in scope. If we delete it from the type env, GHCi crashes because
it doesn't expect that.
]
[MERGE: Figure out where the rest of the repositories are, based on defaultrepo
Ian Lynagh [EMAIL PROTECTED]**2006141531]
[move newSpark() prototype to RtsExternal.h to avoid warnings
Simon Marlow [EMAIL PROTECTED]**20061107115430]
[In hashExpr, use Word32 rather than relying on wrapping behaviour of Int
Simon Marlow [EMAIL PROTECTED]**20061020153925
Fixes #952,
Re: [GHC] #1024: Include cc1plus.exe into GHC distribution for Windows
#1024: Include cc1plus.exe into GHC distribution for Windows -+-- Reporter: guest| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Windows | -+-- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1024 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1024: Include cc1plus.exe into GHC distribution for Windows
#1024: Include cc1plus.exe into GHC distribution for Windows +--- Reporter: guest| Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal |Keywords: Difficulty: Easy (1 hr) |Testcase: Architecture: Multiple | Os: Windows +--- As ticket #800 is solved, it makes perfect sense to include cc1plus.exe into the Windows distribution of GHC. This will allow GHC to compile C++ files. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1024 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1007: Add parsing (and some more) to the time package
#1007: Add parsing (and some more) to the time package -+-- Reporter: [EMAIL PROTECTED] | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other)|Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -+-- Comment (by [EMAIL PROTECTED]): Me like. In more detail: yes, Eq and Ord instances for ZonedTime would be very useful in calendaring applications, together with ranged sets. Furthermore, the parsing really really really is helpful. The printing 'enhancements' seem well argued, and imo should just go in. I'm not so sure about the secondsToDiffTime and picosecondsToDiffTime though. I like the idea of denoting difftimes with integral denotations. The use of fromInteger might be documented better... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1007 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bignums, gmp, bytestring, .. ?
On Nov 22, 2006, at 8:39 PM, Donald Bruce Stewart wrote: p.tanski: to my knowledge, that would be the first Haskell implementation for PalmOS... Pretty sure Tony Sloane et al at Macquarie have had nhc98 running on the palm for quite a while. They've recently moved to YHC though, iirc. Donald, Thanks for tip! Have you seen any of this code yourself? Jeremy, Dr. Sloane would be a good person to contact. For reference, the last work on this seems to have been done in 2005. Tony Sloane (asloane -at- ics dot mq dot edu dot au). Patroklos Argyroundis did a port of GMP version 3.1.1 to WinCE, noted at http://ntrg.cs.tcd.ie/~argp/software/ntrg-gmp-wince.html . I don't know if that might give any good pointers. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] SYB Documentation is inconclusive.
L.S., lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like: totable :: [RecordType] - [[String]] totable rs = fields (head rs) ++ map showrecord rs where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a showrecord = gmapQ (show . toConstr) However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records. Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself. So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to? Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] base libraries
This is a small reply to clarify the regular expression situation: Bulat Ziganshin wrote: Hello libraries, after analyzing the situation, i concluded that source of problem, at least partially, is GHC HQ's policy of packaging libraries with GHC. The list of such libraries is *closed* and odd at first look. why, for example, it includes 2 of 4 regexp libs? at last end, we can learn that this is the list of libs required to build ghc itself! Some of the other regex-* libraries are interfaces to c-library backends (pcre and tre) and it is not GHC's place to come with copies of those libraries. But GHC used regex internally, so it must come with at least a single backend. [...snip...] and while we are here - splitting of Base library should be very easy task. its ghc version specific part is in GHC.* modules. these modules should be moved into the new Core library. plus a few modules from Data.* or System.* hierarchy they imports. plus a few modules imported by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at least between various GHC versions. and independent on this work, we can always look into moving pieces of Base into independent libs. as a rule of thumb, everything not used in Base lib may be moved outside of it. of course, these new libs should be included in base libs set The regex-* modules that are installed with GHC are not in the base package. They are in regex-base and regex-posix and regex-compat because I took excellent design advice and finely split the modules. I see no reason one could not by able to upgrade these on top of the GHC versions. in particular, my hottest hope is that ghc 6.6.1 will be shipped with fps 0.8 as separate library that will provide both backward compatibility with 6.6 and will allow to upgrade fps without recompiling ghc itself :D By separate library you really mean using a separate package name instead of base. The Text.XHtml is already separate into the xhtml package. You are correct: as far as I can see the only module that is in base which might need to be split out is Data.ByteString. The same may or may not apply to Data.Sequence. Cheers, Chris ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] SimonPJ and Tim Harris explain STM - video
http://channel9.msdn.com/Showpost.aspx?postid=231495 The links to the video are a couple of yellow buttons at the bottom of the article: Watch or Download. I haven't watched this yet (it's nearly an hour long, I think). Found via reddit (http://reddit.com). Haskeller's on TV (sort of...) woot woot! Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On 23/11/06, Jason Dagit [EMAIL PROTECTED] wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones – the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write(called doSomething execution# + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
Thanks,
Jason
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x - launchMissiles
if (x 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow this. The content of a transaction may only
include reads and writes to shared memory, along with pure
computations. This is especially easy in Haskell, because one simply
uses a new monad STM, with no way to lift IO actions into that monad,
but atomically :: (STM a - IO a) goes in the other direction, turning
a transaction into IO. In other languages, you'd want to add some
static typechecking to ensure that this constraint was enforced.
- Cale
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
[sorry for quoting so much, kinda hard to decide here where to snip]
Cale Gibbard wrote:
On 23/11/06, Jason Dagit [EMAIL PROTECTED] wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones ? the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write(called doSomething execution# + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x - launchMissiles
if (x 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow this. The content of a transaction may only
include reads and writes to shared memory, along with pure
computations. This is especially easy in Haskell, because one simply
uses a new monad STM, with no way to lift IO actions into that monad,
but atomically :: (STM a - IO a) goes in the other direction, turning
a transaction into IO. In other languages, you'd want to add some
static typechecking to ensure that this constraint was enforced.
This is of course the technically correct answer. However, I suspect that it
may not be completely satisfying to the practitioner. What if you want or
even need your output to be atomically tied to a pure software transaction?
One answer is in fact to make it so that Console.Write can be rolled back
too. To achieve this one can factor the actual output to another task and
inside the transaction merely send the message to a transactional channel
(TChan):
atomic $ do
increment counter
counterval - readvar counter
sendMsg msgChan (called doSomething execution# ++ show counterval)
-- something which could cause the transaction to restart
Another task regularly takes messages from the channel and actually outputs
them. Of course the output will be somewhat delayed, but the order of
messages will be preserved between tasks sending to the same channel. And
the message will only be sent if and only if the transaction commits.
Unfortunately I can't see how to generalize this to input as well...
Cheers
Ben
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] SYB Documentation is inconclusive.
Arthur, constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/DataCon.lhs; and that abstract syntax promises to be order-preserving. It says (not surprisingly): dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity. gmapQ maps the children to results. Since it is a map, it is order-preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr). So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order? Let me know if I don't get what you are after ... perhaps in the café. Ralf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arthur van Leeuwen Sent: Thursday, November 23, 2006 12:09 AM To: haskell@haskell.org Subject: [Haskell] SYB Documentation is inconclusive. L.S., lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like: totable :: [RecordType] - [[String]] totable rs = fields (head rs) ++ map showrecord rs where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a showrecord = gmapQ (show . toConstr) However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records. Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself. So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to? Doei, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] SYB Documentation is inconclusive.
On 23-nov-2006, at 23:22, Ralf Lammel wrote: Arthur, constrFields eventually returns some mangled strings from the abstract syntax tree; see ghc-fptools/ghc/compiler/basicTypes/ DataCon.lhs; and that abstract syntax promises to be order-preserving. It says (not surprisingly): dcFields :: [FieldLabel], -- Field labels for this constructor, in the -- same order as the argument types; -- length = 0 (if not a record) or dataConSourceArity. gmapQ maps the children to results. Since it is a map, it is order- preserving. There is not even any associatively business in the case of gmapQ (as opposed to gmapQl and gmapQr). So zipping together results from gmapQ and constrFields plus handling the special case of non-record types, should be just fine, no? What could possibly go wrong? Perhaps you are saying that the documentation of constrFields should promise explicitly that it does not mangle order? Such a promise would have been nice. I assumed that The Right Thing (as in no magic reorderings) would happen, but it was unclear from the papers and the haddock documentation. I should've looked into the source, of course, as that is the definitive documentation. :) Let me know if I don't get what you are after ... perhaps in the café. You have fully understood and explained. Glad to see that The Right Thing is done. Now I can safely go and let my code into the hands of unsuspecting non-Haskellers. :) With regards, Arthur van Leeuwen. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: PQC: QuickCheck in the Age of Concurrency
PQC: QuickCheck in the Age of Concurrency An SMP parallel QuickCheck driver Do you: * Have (or want) lots of QuickCheck properties? * Run them often (maybe on every darcs commit)? * Tired of waiting for the testsuite to finish? * Got a multi-core box with cpus sitting idle...? Yes? You need Parallel QuickCheck! PQC provides a single module: Test.QuickCheck.Parallel. This is a QuickCheck driver that runs property lists as jobs in parallel, and will utilise as many cores as you wish, with the SMP parallel GHC 6.6 runtime. It is simple, scalable replacement for Test.QuickCheck.Batch. An example, on a 4 cpu linux server, running 20 quickcheck properties. With 1 thread only: $ time ./a.out 1 1: sort1: OK, 1000 tests. 1: sort2: OK, 1000 tests. 1: sort3: OK, 1000 tests. 1: sort4: OK, 1000 tests. ... ./a.out 1 x 18.94s user 0.01s system 99% cpu 18.963 total 18 seconds, 99% cpu. But I've got another 3 2.80GHz processors sitting idle! Let's use them, to run the testsuite faster. No recompilation required. 4 OS threads, 4 Haskell threads: $ time ./a.out 4 +RTS -N4 /dev/null ./a.out 4 +RTS -N4 /dev/null 20.65s user 0.22s system 283% cpu 7.349 total 283% cpu, not bad. We're getting close to being limited by the length of the longest running test. Or on a dual core macbook, thanks to Spencer Janssen for macbook data and testing: 1 thread: ./Example 1 17.256s 2 threads: ./Example 2 +RTS -N2 10.402s Get it! Homepage: http://www.cse.unsw.edu.au/~dons/pqc.html Haddocks: http://www.cse.unsw.edu.au/~dons/pqc/ Example : http://www.cse.unsw.edu.au/~dons/code/pqc/examples/Example.hs darcs get http://www.cse.unsw.edu.au/~dons/code/pqc Happy, quick checking, Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Difficult memory leak in array processing
Hi everyone, I have the following code whose purpose is to add dither (noise) to a given array. The code looks very straightforward but apparently it has a memory leak somewhere. Here I try to run the algorithm for an array of 10,000,000 integers. Ten million unboxed strict integers should equal to 40MB which should pose no problems to any modern system. However, the program fails with a stack overflow error. I'm using GHC 6.6 on Windows with 1 GB of RAM. I've tried applying seq and some other strictness tricks (such as x == x) pretty much everywhere on the code with no results. Could you please help me understand what is going on here? Have I misunderstood something critical in how Haskell works? Here is the relevant portion of the code: module Main where import Data.Array.IO import System.Random type Buffer = IOUArray Int Int -- | Triangular Probability Density Function, equivalent to a roll of two dice. -- The number sums have different probabilities of surfacing. tpdf :: (Int, Int) - IO Int tpdf (low, high) = do first - getStdRandom (randomR (low, high)) second - getStdRandom (randomR (low, high)) return ((first + second) `div` 2) -- | Fills an array with dither generated by the specified function. genSeries :: Buffer - ((Int, Int) - IO Int) - (Int, Int) - IO () genSeries buf denfun lims = let worker low i | i = low = do r - denfun lims writeArray buf i r worker low (i - 1) | otherwise = return () in do (lo, hi) - getBounds buf worker lo hi main = do -- This should allocate a 40 MB array buf - newArray_ (0, 1000) :: IO Buffer -- Fill the array with dither genSeries buf tpdf (2, 12) -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficult memory leak in array processing
Hi Niko, to, 2006-11-23 kello 12:11 +0200, Niko Korhonen kirjoitti: I've tried applying seq and some other strictness tricks (such as x == x) pretty much everywhere on the code with no results. Could you please help me understand what is going on here? Have I misunderstood something critical in how Haskell works? Here is the relevant portion of the code: main = do -- This should allocate a 40 MB array buf - newArray_ (0, 1000) :: IO Buffer -- Fill the array with dither genSeries buf tpdf (2, 12) main = do -- This should allocate a 40 MB array buf - newArray_ (0, 1) :: IO Buffer -- Fill the array with dither genSeries buf tpdf (2, 12) a - readArray buf 1 putStrLn $ a is ++ (show a) By adding -O3 -optc-O3 -funfolding-use-threshold=16 compile flags the above code with 100'000'000 elements worked. And by still adding -ddump-simpl core.txt flag and looking the generated core, the worker-loop seemed to use primitives. I cannot say, if this was the helping part here. Have you tried profiling: -prof -auto-all and running with +RTS -p -RTS? Or running with +RTS -sstderr gives 14,257,786,344 bytes allocated in the heap 4,282,040 bytes copied during GC (scavenged) 1,646,936 bytes copied during GC (not scavenged) 80,733,232 bytes maximum residency (2 sample(s)) 27045 collections in generation 0 ( 0.31s) 2 collections in generation 1 ( 0.00s) 78 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 22.61s ( 24.07s elapsed) GCtime0.31s ( 0.32s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 22.92s ( 24.39s elapsed) %GC time 1.3% (1.3% elapsed) Alloc rate630,612,876 bytes per MUT second Productivity 98.6% of total user, 92.7% of total elapsed It seems that garbage collector has not used very much time here. There is more information on haskell wiki: http://www.haskell.org/haskellwiki/Performance http://www.haskell.org/haskellwiki/Performance/GHC This GHC specific part does not mention -O3 -optc-O3 -funfolding-use-threshold=nn flags. They were hinted here on this list; I have found them very helpful a couple of weeks ago - thanks again :) btw, Could the GHC specific wiki page be updated to contain and explain these flags? Hopefully this helped you a bit! And hopefully someone who knows how these things go have time to give you a detailed answer! br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SimonPJ and Tim Harris explain STM - video
http://channel9.msdn.com/Showpost.aspx?postid=231495 The links to the video are a couple of yellow buttons at the bottom of the article: Watch or Download. I haven't watched this yet (it's nearly an hour long, I think). Found via reddit (http://reddit.com). Haskeller's on TV (sort of...) woot woot! Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficult memory leak in array processing
Niko Korhonen wrote: I have the following code whose purpose is to add dither (noise) to a given array. The code looks very straightforward but apparently it has a memory leak somewhere. No, it doesn't. It can't, because it doesn't even compile. After correcting the obvious (lo, hi) - getBounds buf to let (lo,hi) = bounds buf it just works and needs 40MB plus epsilon. Your problem has to be somewhere else. -Udo. -- fork(2) New processes are created by other processes, just like new humans. New humans are created by other humans, of course, not by processes. -- Unix System Administration Handbook signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Difficult memory leak in array processing
Ah, yet another UndeadArray necromancer exhausting his stack of bones. May the forces of light suggest to structure the incantation of darkness? modifyArray arr i f = readArray arr i = \y - writeArray arr i (f y) accumM :: (MArray a e m, Ix i) = (e - e' - e) - a i e - [(i, e')] - m () accumM f arr xs = mapM_ chg xs where chg (i,x) = modifyArray arr i (flip f x) twodice (x:x':xs) = (x+x') `div` 2 : twodice xs noise rng gen = twodice $ randomRs rng gen main = do let bnds = (0, 1000) buf - newArray_ bnds :: IO Buffer gen - getStdGen accumM (curry snd) buf $ zip (range bnds) $ noise (2,12) gen I absolutely don't know why there is no (accumM) function in the standard libraries. And having the ByteString API (maybe even the fusion) for general arrays would be very nice. Maybe (modifyArray) is missing, too. Regards, apfelmus PS: did you try worker low (i `seq` i-1) ? PSS: The strictness analyzer is likely to insert that automatically if you compile with -O or -O2. Niko Korhonen wrote: Hi everyone, I have the following code whose purpose is to add dither (noise) to a given array. The code looks very straightforward but apparently it has a memory leak somewhere. Here I try to run the algorithm for an array of 10,000,000 integers. Ten million unboxed strict integers should equal to 40MB which should pose no problems to any modern system. However, the program fails with a stack overflow error. I'm using GHC 6.6 on Windows with 1 GB of RAM. I've tried applying seq and some other strictness tricks (such as x == x) pretty much everywhere on the code with no results. Could you please help me understand what is going on here? Have I misunderstood something critical in how Haskell works? Here is the relevant portion of the code: module Main where import Data.Array.IO import System.Random type Buffer = IOUArray Int Int -- | Triangular Probability Density Function, equivalent to a roll of two dice. -- The number sums have different probabilities of surfacing. tpdf :: (Int, Int) - IO Int tpdf (low, high) = do first - getStdRandom (randomR (low, high)) second - getStdRandom (randomR (low, high)) return ((first + second) `div` 2) -- | Fills an array with dither generated by the specified function. genSeries :: Buffer - ((Int, Int) - IO Int) - (Int, Int) - IO () genSeries buf denfun lims = let worker low i | i = low = do r - denfun lims writeArray buf i r worker low (i - 1) | otherwise = return () in do (lo, hi) - getBounds buf worker lo hi main = do -- This should allocate a 40 MB array buf - newArray_ (0, 1000) :: IO Buffer -- Fill the array with dither genSeries buf tpdf (2, 12) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Difficult memory leak in array processing
Udo Stenzel wrote: Niko Korhonen wrote: I have the following code whose purpose is to add dither (noise) to a given array. The code looks very straightforward but apparently it has a memory leak somewhere. No, it doesn't. It can't, because it doesn't even compile. After correcting the obvious (lo, hi) - getBounds buf to let (lo,hi) = bounds buf The interface changed between GHC 6.4.2 and 6.6. But no honorable Haskell paladin would ever dare to use UndeadArrays. it just works and needs 40MB plus epsilon. Your problem has to be somewhere else. The strictness analyzer likes Udo more than Niko, does it? Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] LLVM back end
On 20 Nov 2006, at 08:27, Michael T. Richter wrote: I've been eyeing LLVM[1] as interesting technology -- brief executive summary: a virtual machine suited as the back end of compiler output with optimised native code then coming from it as either JIT-based execution of the LLVM bytecode or as a further compilation step -- and couldn't help but immediately think of the possibility of one of the Haskell compiler projects providing an LLVM code generator. I think this would help in several areas: it could make porting the compiler to other architectures -- including oddball ones that would be too small to otherwise support -- easier; it could help remove the nigh-ubiquitous reliance upon GCC as a back-end (while I think that GCC is a pretty good piece of software, I'm not sure it's really suited to its current role as the do-everything back end); it could leverage some of the really interesting work that's going on in optimisation technology by letting one VM's optimiser do the work for any number of languages; it could improve interaction between source code written in multiple languages. Is this me opening up a Pandora's Box of ignorance here? Or is LLVM potentially interesting? (And were someone motivated into perhaps trying to make an LLVM back-end, where would one start to poke around in, say, the GHC codebase to even begin to implement this? And how insane would they be driven by the process?) I've been looking at LLVM for a while too now, for research purposes. And one of the big downsides (at least for me), is the lack of a real simulator which mimicks the virtual machine. They do have a JIT compiler which allows you to execute LLVM bytecode on a number of platforms, but I'm interested in analyzing the dynamic behaviour of the LLVM bytecode, and JIT'ing doesn''t allow that. They also have an interpreter, which is probably quite similar to a simulator, but that's just horrible slow because of the SSA (hence, no registers) system used. To get to the point: I think Haskell might be a great candidate for building an LLVM bytecode simulator. I have been thinking about it, but because of my lack of coding experience (and understanding of Monads), I haven't started a project yet. If some people would be interested in such a thing though, we might join to make this a succes. I'm not LLVM expert, and surely no Haskell expert either, but I think such a project can be pretty interesting. greetings, Kenneth -- Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital (Aaron Levenstein) Kenneth Hoste ELIS - Ghent University [EMAIL PROTECTED] http://www.elis.ugent.be/~kehoste ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type Error. Why!?
Neil Mitchell schrieb: How is this an FAQ: http://www.haskell.org/haskellwiki/Why_Haskell_just_works It's a nice piece of marketing, but I can't imagine anyone has ever asked Why Haskell just works, unless they've already used it, in which case they've moved past an FAQ. Oh, but that kind of question regularly crops up after Haskell programmers have claimed that Haskell just works. So yes indeed that's a FAQ. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] list monad and controlling the backtracking
Hi all, Weekly news had a link to article Local and global side effects with monad transformers and the following is from there (minor modification done): import Control.Monad.List import Control.Monad.State import Control.Monad.Writer test5 :: StateT Integer (ListT (Writer [Char])) Integer test5 = do a - lift $ mlist aList b - lift $ mlist bList lift $ lift $ tell (trying ++show a++ ++show b++\n) modify (+1) guard $ a+b5 return $ a+b go5 = runWriter $ runListT $ runStateT test5 0 If the aList = [1..5] as well as bList, then there will be 25 tryings. If aList and bList are [1..1000], there will be a lot of tryings... However, guard is saying that we are interested in only values whose sum is less than 5. Is it possible to control easily in the above example that when we have tried out pairs (1,1), (1,2), (1,3), (1,4), that now we are ready to stop trying from the bList? And then similarly when we finally arrive to a pair (4,1), that now we are ready to finish also with aList? This would give a nice way to build branch bounding algorithms, even though it does not take much more lines to do it in some other way. br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type keeping rounding, typeable (and a difficulty)
Hi thanks! to, 2006-11-16 kello 14:02 -0800, Greg Buchholz kirjoitti: ] I'll guess the reason it didn't compile was different ] types at case branches (am I wrong?) Correct. ] Anyhow, do you know that is it possible to choose the return type ] somehow in the spirit above? Maybe you want something like... This time, however, I'm not sure after seeing oleg's email: http://www.haskell.org/pipermail/haskell/2006-November/018736.html I'll have yet to re-read it carefully to be sure... :) br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: list monad and controlling the backtracking
isto wrote: Hi all, Weekly news had a link to article Local and global side effects with monad transformers and the following is from there (minor modification done): import Control.Monad.List import Control.Monad.State import Control.Monad.Writer test5 :: StateT Integer (ListT (Writer [Char])) Integer test5 = do a - lift $ mlist aList b - lift $ mlist bList lift $ lift $ tell (trying ++show a++ ++show b++\n) modify (+1) guard $ a+b5 return $ a+b go5 = runWriter $ runListT $ runStateT test5 0 If the aList = [1..5] as well as bList, then there will be 25 tryings. If aList and bList are [1..1000], there will be a lot of tryings... However, guard is saying that we are interested in only values whose sum is less than 5. Is it possible to control easily in the above example that when we have tried out pairs (1,1), (1,2), (1,3), (1,4), that now we are ready to stop trying from the bList? And then similarly when we finally arrive to a pair (4,1), that now we are ready to finish also with aList? If I understood you correctly you seem to want a monad that offers something akin to Prolog's cut. You might want to take a look at http://okmij.org/ftp/Computation/monads.html#LogicT Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equivalent of if/then/else for IO Bool?
On 11/23/06, Dougal Stanton [EMAIL PROTECTED] wrote: Is there some sort of equivalent of the if/then/else construct for use in the IO monad? For instance the following can get quite tedious: do bool - doesFileExist filename if bool then sth else sth' Is there a more compact way of writing that? Something akin to: condM (doesFileExist filename) (sth) (sth') Maybe there is one built in but don't know it or see anything in hoogle. I'd use something like the following (and then just make it a standard part of the libraries I use personally): import Control.Monad if' b t e = if b then t else e ifM = liftM3 if' which gives ifM :: (Monad m) = m Bool - m t - m t - m t HTH, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Equivalent of if/then/else for IO Bool?
Dougal Stanton wrote: Is there some sort of equivalent of the if/then/else construct for use in the IO monad? For instance the following can get quite tedious: do bool - doesFileExist filename if bool then sth else sth' Is there a more compact way of writing that? Something akin to: condM (doesFileExist filename) (sth) (sth') Or maybe there's a more sensible way of doing the above that I've missed. I seem to use endless alternate conditions sometimes and there's bound to be a better way. Roll your own control structures! Haskell has higher order functions for a reason. This should do the trick (untested): condM condAction thenBranch elseBranch = do bool - condAction if bool then thenBranch else elseBranch (Hack it into ghci or hugs to find out the type, it's a bit more general than what you need.) Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On 23/11/06, Jason Dagit [EMAIL PROTECTED] wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones – the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write(called doSomething execution# + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
Thanks,
Jason
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x - launchMissiles
if (x 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow this. The content of a transaction may only
include reads and writes to shared memory, along with pure
computations. This is especially easy in Haskell, because one simply
uses a new monad STM, with no way to lift IO actions into that monad,
but atomically :: (STM a - IO a) goes in the other direction, turning
a transaction into IO. In other languages, you'd want to add some
static typechecking to ensure that this constraint was enforced.
- Cale
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
[sorry for quoting so much, kinda hard to decide here where to snip]
Cale Gibbard wrote:
On 23/11/06, Jason Dagit [EMAIL PROTECTED] wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones ? the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write(called doSomething execution# + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x - launchMissiles
if (x 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow this. The content of a transaction may only
include reads and writes to shared memory, along with pure
computations. This is especially easy in Haskell, because one simply
uses a new monad STM, with no way to lift IO actions into that monad,
but atomically :: (STM a - IO a) goes in the other direction, turning
a transaction into IO. In other languages, you'd want to add some
static typechecking to ensure that this constraint was enforced.
This is of course the technically correct answer. However, I suspect that it
may not be completely satisfying to the practitioner. What if you want or
even need your output to be atomically tied to a pure software transaction?
One answer is in fact to make it so that Console.Write can be rolled back
too. To achieve this one can factor the actual output to another task and
inside the transaction merely send the message to a transactional channel
(TChan):
atomic $ do
increment counter
counterval - readvar counter
sendMsg msgChan (called doSomething execution# ++ show counterval)
-- something which could cause the transaction to restart
Another task regularly takes messages from the channel and actually outputs
them. Of course the output will be somewhat delayed, but the order of
messages will be preserved between tasks sending to the same channel. And
the message will only be sent if and only if the transaction commits.
Unfortunately I can't see how to generalize this to input as well...
Cheers
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
(Dropping [EMAIL PROTECTED])
Hi,
We've not yet looked at I/O in detail in Haskell, but there's a paper from a
few years back where I experimented with ways of integrating I/O with an
earlier implementation of atomic blocks in Java.
http://research.microsoft.com/~tharris/papers/2005-scp.pdf
The basic idea is to provide a way for a transaction to call into
transaction-aware libraries. The libraries can register callbacks for if the
transaction commits (to actually do any O) and for if the transaction aborts
(to re-buffer any I that the transaction has consumed). In addition, a
library providing access to another transactional abstraction (e.g. a database
supporting transactions) can perform a 2-phase commit that means that the
memory transaction and database transaction either both commit or both abort.
Of course, these solutions don't deal with the question of atomic blocks that
want to perform output (e.g. to the console) and receive input in response to
that. My view at the moment is _that does not make sense in an atomic block_
-- the output and input can't be performed atomically because the intervening
state must be visible for the user to respond to.
We also briefly experimented with extending the SXM system Maurice Herlihy
worked on at MSR Cambridge to support transactions that include accesses to the
file system and registry --
http://msdn2.microsoft.com/en-us/library/aa366295.aspx describes the TxF and
TxR systems it was built over.
Some other interesting work in this area is Elliot Moss' papers on open
nested transactions -- these provide another building block at the same level
as the Java system I mentioned: library writers can use them with care to
extend the range of things that can be done inside an atomic block.
Cheers,
Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Franksen
Sent: 24 November 2006 03:16
To: haskell@haskell.org
Cc: haskell-cafe@haskell.org
Subject: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
[sorry for quoting so much, kinda hard to decide here where to snip]
Cale Gibbard wrote:
On 23/11/06, Jason Dagit [EMAIL PROTECTED] wrote:
A comment on that video said:
- BEGIN QUOTE
It seems to me that STM creates new problems with composability.
You create two classes of code: atomic methods and non atomic methods.
Nonatomic methods can easily call atomic ones ? the compiler could
even automatically inject the atomic block if the programmer forgot.
Atomic methods and blocks cannot be allowed to call nonatomic code.
The nonatomic code could do I/O or other irrevocable things that would
be duplicated when the block had to retry.
END QUOTE
I imagine an example like this (some pseudo code for a side effect
happy OO language):
class Foo {
protected int counter; // assume this gets initialized to 0
public doSomething() {
atomic{
counter++;
Console.Write(called doSomething execution# + counter);
// something which could cause the transaction to restart
}
}
public doOtherThing() {
atomic{
doSomething();
// something which could cause the transaction to restart
}
}
}
Now imagine doSomething gets restarted, then we see the console output
once each time and counter gets incremented. So one solution would be
to move the side effects (counter++ and the console write) to happen
before the atomic block. This works for doSomething, but now what if
we called doOtherThing instead? We're back to having the extra
side-effects from the failed attempts at doSomething, right? We just
lost composability of doSomething? I'm assuming counter is only meant
to be incremented once per successful run of doSomething and we only
want to see the output to the log file once per successful run, but it
needs to come before the log output inside doSomething so that the log
makes sense.
I realize STM is not a silver bullet, but it does seem like
side-effects do not play nicely with STM. What is the proposed
solution to this? Am I just missing something simple? Is the
solution to make it so that Console.Write can be rolled back too?
The solution is to simply not allow side effecting computations in
transactions. They talk a little about it in the video, but perhaps
that's not clear. The only side effects an atomic STM transaction may
have are changes to shared memory.
Another example in pseudocode:
atomic
x - launchMissiles
if (x 5) then retry
This is obviously catastrophic. If launchMissiles has the side effect
of launching a salvo of missiles, and then the retry occurs, it's
unlikely that rolling back the transaction is going to be able to put
them back on the launchpad. Worse yet, if some variable read in
launchMissiles changes, the transaction would retry, possibly causing
a second salvo of missiles to be launched.
So you simply disallow
Re: [Haskell-cafe] type keeping rounding, typeable (and a difficulty)
On Thu, Nov 16, 2006 at 10:44:59PM +0200, isto wrote: I'll guess the reason it didn't compile was different types at case branches (am I wrong?) Anyhow, do you know that is it possible to choose the return type somehow in the spirit above? GADTs let you do this. And they even omit the run time type check. though, the type class solution is the correct way to do this sort of thing. data Value a where IntLike :: Int - Value Int CharLike :: Char - Value Char f :: Value a - a f x = case x of IntLike x - x + 1 CharLike x - x: plus one there is also Data.Dynamic and existential types which are related to the task. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equivalent of if/then/else for IO Bool?
You can use 'when' or 'unless' from the module Control.Monad, but they
each have only one branch, see:
http://members.chello.nl/hjgtuyl/tourdemonad.html#unless
and
http://members.chello.nl/hjgtuyl/tourdemonad.html#when
You can create a monadic 'if' like this (in an interactive session):
Control.Monad let ifM p a b = do { p' - p; if p' then return a else
return b } in ifM (Just True) 1 2
Just 1
Met vriendelijke groet,
Henk-Jan van Tuyl
--
On Thu, 23 Nov 2006 22:34:49 +0100, Dougal Stanton [EMAIL PROTECTED]
wrote:
Is there some sort of equivalent of the if/then/else construct for use
in the IO monad? For instance the following can get quite tedious:
do bool - doesFileExist filename
if bool
then sth
else sth'
Is there a more compact way of writing that? Something akin to:
condM (doesFileExist filename) (sth) (sth')
Or maybe there's a more sensible way of doing the above that I've
missed. I seem to use endless alternate conditions sometimes and there's
bound to be a better way.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
http://Van.Tuyl.eu/
--
Using Opera's revolutionary e-mail client:
https://secure.bmtmicro.com/opera/buy-opera.html?AID=789433
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
Hi, On 23/11/06, Benjamin Franksen [EMAIL PROTECTED] wrote: One answer is in fact to make it so that Console.Write can be rolled back too. To achieve this one can factor the actual output to another task and inside the transaction merely send the message to a transactional channel (TChan): So, you could simply return the console output as (part of) the result of the atomic action. Wrap it in a WriterT monad transformer, even. (one, console) - atomic $ runWriterT $ do tell hello world\n return 1 putStr console (Not terribly efficient, but you get the idea.) You're just calculating what output to make inside the transaction; the actual outputting happens outside, once the transaction commits. Another task regularly takes messages from the channel With STM, the outputter task won't see any messages from the channel until your main atomic block completes, after which you're living in IO-land, so you might as well do the output yourself. Pugs/Perl 6 takes the approach that any IO inside an atomic block raises an exception. Unfortunately I can't see how to generalize this to input as well... The dual of how you described the output situation: read a block of input before the transaction starts, and consume this during the transaction. I guess you're not seeing how this generalises because potentially you won't know how much of the input you will need to read beforehand... (so read all available input?(!) You have the dual situation in the output case, in that you can't be sure how much output it may generate / you will need to buffer.) input - hGetContent file atomic $ flip runReaderT input $ do input - ask -- do something with input return 42 (This is actually a bad example, since hGetContents reads the file lazily with interleaved IO...) later, /Liyang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] working with lists of couples
Yes the code you are suggesting is certainly linear and it takes without doubt time n. But I was looking for a solution using foldl that of course takes time n. The problem of the following solution is that it gives a reversed result, and of course i can't just reverse the result. couples = snd . foldl f (0,[]) where f (s,[]) x = (s+x, [(x,0)]) f (s,xs) x = (s+x, (:) (x,s) xs) Clare 2006/11/17, Valentin Gjorgjioski [EMAIL PROTECTED]: On 17.11.2006 21:04 Clare wrote: I'm not sure it takes time n couse of the operator ++ and the lazy stuffs in haskell. Ok, you can use buildCouples (x:xs) s = (x,s) : (buildCouples xs (x+s)) instead of ++ this algorithm is linear, I don't know why(?) you think it is not. Valentin -- Valentin Gjorgjioski Bachelor of Computer Science Department of Knowledge Technologies, Jozef Stefan Institute Jamova 39, SI-1000 Ljubljana, Slovenia Phone: +386 1 477 3343 Fax:+386 1 477 3315 Web:http://kt.ijs.si/ValentinGjorgjioski/ Email: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equivalent of if/then/else for IO Bool?
Jason Dagit wrote: On 11/23/06, Dougal Stanton [EMAIL PROTECTED] wrote: Is there some sort of equivalent of the if/then/else construct for use in the IO monad? For instance the following can get quite tedious: do bool - doesFileExist filename if bool then sth else sth' Is there a more compact way of writing that? Something akin to: condM (doesFileExist filename) (sth) (sth') Maybe there is one built in but don't know it or see anything in hoogle. I'd use something like the following (and then just make it a standard part of the libraries I use personally): import Control.Monad if' b t e = if b then t else e ifM = liftM3 if' which gives ifM :: (Monad m) = m Bool - m t - m t - m t No! You can really screw up this way... Your function will perform the effects of the Bool and *both* branch computation in sequence, then use the returned Bool value to select between the returned 'then' value and the returned 'else' value. Do not use it to operate machinery! *Grr ifM (Just True) (Just 3) Nothing Nothing More care required! Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: SimonPJ and Tim Harris explain STM - video
Hi Liyang HU you wrote: On 23/11/06, Benjamin Franksen [EMAIL PROTECTED] wrote: One answer is in fact to make it so that Console.Write can be rolled back too. To achieve this one can factor the actual output to another task and inside the transaction merely send the message to a transactional channel (TChan): So, you could simply return the console output as (part of) the result of the atomic action. Wrap it in a WriterT monad transformer, even. But this would break atomicity, wouldn't it? Another call to doSomething from another task could interrupt before I get the chance to do the actual output. With a channel whatever writes will happen in the same order in which the STM actions commit (which coincides with the order in which the counters get incremented). Another task regularly takes messages from the channel With STM, the outputter task won't see any messages from the channel until your main atomic block completes, after which you're living in IO-land, so you might as well do the output yourself. Yeah, right. Separate task might still be preferable, otherwise you have to take care not to forget to actually do the IO after each transaction. I guess it even makes sense to hide the channel stuff behind some nice abstraction, so inside the transaction it looks similar to a plain IO action: output port msg The result is in fact mostly indistiguishable from a direct IO call due to the fact that IO is buffered in the OS anyway. Pugs/Perl 6 takes the approach that any IO inside an atomic block raises an exception. Unfortunately I can't see how to generalize this to input as well... The dual of how you described the output situation: read a block of input before the transaction starts, and consume this during the transaction. I guess you're not seeing how this generalises because potentially you won't know how much of the input you will need to read beforehand... (so read all available input?(!) You have the dual situation in the output case, in that you can't be sure how much output it may generate / you will need to buffer.) You say it. I guess the main difference is that I have a pretty good idea how much data is going to be produced by my own code, and if it's a bit more than I calculated then the whole process merely uses up some more memory, which is usually not a big problem. However, with input things are different: in many cases the input length is not under my control and could be arbitrarily large. If I read until my buffer is full and I still haven't got enough data, my transaction will be stuck with no way to demand more input. (however, see below) input - hGetContent file atomic $ flip runReaderT input $ do input - ask -- do something with input return 42 (This is actually a bad example, since hGetContents reads the file lazily with interleaved IO...) In fact reading everything lazily seems to be the only way out, if you don't want to have arbitrary limits for chunks of input. OTOH, maybe limiting the input chunks to some maximum length is a good idea regardless of STM and whatnot. Some evil data source may want to crash my process by making it eat more and more memory... So, after all you are probably right and there is an obvious generalization to input. Cool. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Command line prompt templates
ithika: I was trying to write my own equivalent to Don Stewart's mkcabal but ended up getting sidetracked. I made some generalised prompts for use at the command line and wanted to get some feedback on them. The full code can be found at [1] but the basic summary is like this: prompt :: String - IO String Simple prompt - supply a question and receive the user's answer. promptYesNo :: String - Maybe String - IO Bool A yes/no question, with an optional value to ask about. I suppose this could be simplified to just one string. promptList :: String - [String] - Maybe Integer - IO Integer Ask the user to choose from a list, where the result is the number chosen. The optional value is a default if the user doesn't pick a number. promptListEdit :: String - [String] - Maybe Integer - IO String As above, but the last option in the list is an invitation to provide your own answer. Again the optional value is the default choice if nothing else is chosen. The result here is necessarily the string rather than the integer cos I didn't want to complicate matters further with stuff like Either types. If you can see any flaws or have any suggestions please let me know! Looks pretty good, though you use case x :: Bool of True - ... False - ... when if x then ... else ... would be preferred. I wonder if there's a prompt API out there for python or something you could use for inspiration? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange type mismatch when trying to use takusen
I have a simple test program for takusen and PostgreSQL: import Database.Enumerator import Database.PostgreSQL.Enumerator import Control.Monad.Trans gazdbSession dbname = connect [CAdbname dbname] resultCollector :: (Monad m) = String - IterAct m [String] resultCollector str accum = result' (str:accum) main = do withSession (connect [CAdbname template1]) $ main' main' = do r - doQuery (sql select 'fred') resultCollector [] liftIO $ putStrLn $ show r But it won't compile: [1 of 1] Compiling Main ( takusen-test.hs, takusen-test.o ) takusen-test.hs:11:57: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `DBM mark sess ()' In the second argument of `($)', namely `main'' In the expression: (withSession (connect [CAdbname template1])) $ main' In the expression: do (withSession (connect [CAdbname template1])) $ main' Adding an explicit main' :: DBM mark Session () type signature doesn't change the error message. The takusen source that I'm using was updated from darcs on November 14 and compiled with ghc 6.6. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equivalent of if/then/else for IO Bool?
Dougal Stanton wrote: Is there some sort of equivalent of the if/then/else construct for use in the IO monad? For instance the following can get quite tedious: do bool - doesFileExist filename if bool then sth else sth' Is there a more compact way of writing that? Something akin to: condM (doesFileExist filename) (sth) (sth') Or maybe there's a more sensible way of doing the above that I've missed. I seem to use endless alternate conditions sometimes and there's bound to be a better way. I don't know any existing function like this in the current libs. Here i paste probably a possible implementation for one. if' :: (Monad m) = m Bool - m b - m b - m b if' mb mt mf = mb = if'' where if'' b = if b then mt else mf Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange type mismatch when trying to use takusen
On 11/23/06, Seth Gordon [EMAIL PROTECTED] wrote: takusen-test.hs:11:57: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `DBM mark sess ()' In the second argument of `($)', namely `main'' In the expression: (withSession (connect [CAdbname template1])) $ main' In the expression: do (withSession (connect [CAdbname template1])) $ main' Ah, the dreaded $ with existential types problem. $ is not quite equivalent to application -- the type checker does something funny with forall types. Just take out the $ and you'll be fine. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about How to Write a Haskell Program tutorial
mvanier: First off, I apologize if this has come up before. As far as I can tell, the mailing list archives don't have a search function. I'm running ghc-6.6 and haddock-0.8, both compiled from source. I'm working my way through the How to Write a Haskell Program tutorial (which is a great idea, thanks guys!), and everything works fine until I get to the part about creating the haddock documentation. When I run: $ runhaskell Setup.hs haddock I get this: Preprocessing executables for haq-0.0... Running Haddock for haq-0.0... Warning: cannot use package haq-0.0: ghc-pkg failed With verbosity: $ runhaskell Setup.hs haddock -v I get this: Preprocessing executables for haq-0.0... Running Haddock for haq-0.0... /usr/local/packages/haskell-misc/bin/haddock --html --odir=dist/doc/html/haq --title=haq --use-package=haq-0.0 --use-package=base-2.0 dist/build/tmp/Haq.hs Warning: cannot use package haq-0.0: ghc-pkg failed Ah yes, I get this too when using ghc 6.6. With ghc 6.4.2 the haddock goes through fine. Updating haddock to 0.8 and the ghc-pkg error is still there. But the docs seem to be generated ok: Main Synopsis main :: IO () Documentation main :: IO () main runs the main program Produced by Haddock version 0.8 Simon, know what's going on? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Command line prompt templates
Donald Bruce Stewart wrote: Looks pretty good, though you use case x :: Bool of True - ... False - ... when if x then ... else ... would be preferred. Why? Personally, I find boolean case to feel better wrt layout and I see no loss of clarity in its use. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
