Re: [Haskell-cafe] Re: [Haskell] Re: Streams: the extensible I/O library
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 complex datastructures PS | Chasing modules from: wc.hs PS | [ 1 of 16] Compiling System.FD( ../System/FD.hs, ../System/FD.o ) PS | PS | /tmp/ghc9376_0.hc:6:16: io.h: No such file or directory PS | /tmp/ghc9376_0.hc: In function `SystemziFD_zdwccall_entry': it should be replaced by HsBase.h, i erroneously thinks that io.h is available on Unix systems. HsBase.h determines itself where we can find all definitions of these low-level functions PS | warning: implicit declaration of function `_eof' it should be eof PS | warning: implicit declaration of function `filelength' it should be found via HsBase.h, is not? PS | warning: implicit declaration of function `tell' ditto PS I also downloaded the new release archive, just to be sure. but PS it doesn't contain a file io.h either. Is that a system header? yes, in mingw :) i attached updated FD.hs. but if filelength/tell cannot be found through HsBase.h, i don't know what to do. at least, System.Posix.Internals does the same: #include ghcconfig.h #include HsBaseConfig.h foreign import ccall unsafe HsBase.h read c_read :: CInt - Ptr CChar - CSize - IO CSsize foreign import ccall unsafe HsBase.h write c_write :: CInt - Ptr CChar - CSize - IO CSsize it is possible that devil is in the including of those two additional files. try to add it. otherwise, we should wait until Simon be up :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] FD.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: EclipseFP (Haskell IDE) 0.9.1 released
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 to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device. I do that on my PDA phone sometimes, usually when I'm having a coffee with some buddy discussing this or that algorithm :) Thanks to whoever ported Hugs for Windows CE (I don't remember the url now) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: extending bang proposal Re: strict Haskell dialect
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 thunk still has to be created at the call site because the compiler can't possibly know that it's going to be immediately evaluated by seq. GHC solves this with the worker-wrapper transformation: the code for the wrapper is exported as part of the module's interface and inlined at external call sites. It handles seq, unboxing, and so on and calls the worker via a private interface. Not that I think strictness information in the type system is a bad idea. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell reference card ?
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, what is the current plan for the old wiki? Should new improvements be made to the new wiki (http://haskell.org/haskellwiki/...) instead of the old one (http://haskell.org/hawiki/...) ? Is the old wiki supposed to get gradually merged into the new wiki/website? I understand it would be a bad idea to take it down (so it will probably be there for a long time) but is it supposed to be deprecated any time soon? Jared. On 2/7/06, Neil Mitchell [EMAIL PROTECTED] wrote: is there somewhre Haskell reference card ? I attempted to start one quite a while ago: http://www.nmitchell.co.uk/code/haskell.htm But its not complete, and it was quite a while ago, so it may be wrong (but on the other hand, it may be useful) I also attempted to start a keyword list on the old haskell wiki http://www.haskell.org/hawiki/Keywords Perhaps there should be a wiki page for this? In which case, people are welcome to copy either of those above pages. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: extending bang proposal Re: strict Haskelldialect
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 body itself means that the thunk still has to be created at the call site because the compiler can't possibly know that it's going to be immediately evaluated by seq. GHC solves this with the worker-wrapper transformation: the code for the wrapper is exported as part of the module's interface and inlined at external call sites. It handles seq, unboxing, and so on and calls the worker via a private interface. Not that I think strictness information in the type system is a bad idea. Sounds cool. I wonder if strictness annotations are ever really needed (eg if the perfect optimizer were possible to construct)? One problem I see with strictness annotations in functions is that there could easily be an exponential growth in variants of a function (and callers of that function...) to handle different strictness requirements (eg for map with all of Clean's list types etc) leading to a bit of a minefield for the humble programmer... :-) Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does haskell have plist's ?
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, raptor [EMAIL PROTECTED] wrote: does Haskell have a property lists. Like Lisp ? any pointer to examples ? Not built in to the language. It's not hard to get the same functionality though - I've attached a module that takes a (not tremendously elegant) approach to the same thing, though. You'll have to store PLists explicitly, though, and this requires GHC. /g -- We have lingered in the chambers of the sea By sea-girls wreathed with seaweed red and brown Till human voices wake us, and we drown. PList.hs___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Fast Mutable Variables for the IO and ST monads
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 to introduce a class Unpackable as described at the end of http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html so we may define STUArray as an instance of MArray, and other similar unpackable things easier? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why is $ right associative instead ofleftassociative?
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 the identifiers the syntactic sugar expands into. So you could keep the current list-only comprehension as default, and allow monad comprehension by providing a library (which the users need to import so as to hide the Prelude's definition). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Fast Mutable Variables for the IO and ST monads
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, ForeignPtr, StablePtr, Bool. opc Perhaps it may be worth to introduce a class Unpackable as described opc at the end of opc http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html opc so we may define STUArray as an instance of MArray, and other similar opc unpackable things easier? btw, there is a class Storable. although it serves diffrent purposes, at least the members are the same -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
