Hello Peter,
Tuesday, February 07, 2006, 4:05:55 AM, you wrote:
PS | Examples$ ghc -i.. -O2 -funbox-strict-fields --make wc.hs -o wc
btw, in my programs (and in this lib) i explicitly unbox all the
strict fields with simple types because automatic unboxing can lead
to losed sharing of
Graham Klyne [EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
One of the features of Haskell that I like is that it doesn't require lots
of
IDE support to write complex programs... the compact syntax and clean
separation
of concerns that can be achieved make it iasy enough
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can allow
the compiler to avoid creating thunks at the call site for cross-module
calls whereas using seq in the function body itself means that the
On the new wiki, there is a keyword page as well (probably copied from
the old wiki):
http://haskell.org/haskellwiki/Keywords
I agree that it would be nice to have a reference card page much
like yours, Neil. So I made it on the wiki:
http://www.haskell.org/haskellwiki/Reference_card
By the way,
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can
allow the compiler to avoid creating thunks at the call site for
cross-module calls whereas using seq in the function
I just wanted to say thanks for posting that, I have been struggling
with a similar problem and I still haven't fully wrapped my head around
Typeable and fundeps so that PList code you posted helped immensely.
Cheers,
Scott
On 05/02/2006, at 3:57 AM, J. Garrett Morris wrote:
On 2/4/06,
Simon Marlow wrote:
I suggest you follow the same scheme as the unboxed array types, and
have IOURef/STURef types, parameterised over the element type. Of
course, we should have instances for all of the primitive numeric types
plus Ptr, ForeignPtr, StablePtr, Bool.
Perhaps it may be worth
The trouble with monad comprehensions was that it became far too easy to
write ambiguous programs, even when you thought you were just working with
lists.
One solution was already suggested: to make the comprehension syntax be pure
syntactic sugar whose semantics depends on the semantics of
Hello oleg,
Wednesday, February 08, 2006, 8:37:55 AM, you wrote:
I suggest you follow the same scheme as the unboxed array types, and
have IOURef/STURef types, parameterised over the element type. Of
course, we should have instances for all of the primitive numeric types
plus Ptr,
