- Libraries - Haskell.org

Re: [Haskell] ANNOUNCE: new FGL version (April 2007)
by Andrew Wagner 03 Apr '07

03 Apr '07

Martin, Thanks for your work on this very interesting library. For the record, I was able to build it here on an x86 architecture under ghc 6.6, but only with -fglasgow-exts, and one other minor tweak. If anyone wants details, let me know. Andrew On 4/2/07, Martin Erwig <erwig(a)eecs.oregonstate.edu> wrote: > FGL - A Functional Graph Library, Version: April 2007 > ===================================================== > > A new release of the Functional Graph Library for Haskell > is available at: > > http://eecs.oregonstate.edu/~erwig/fgl/haskell/ > > This release fixes some bugs in the implementation of > several basic inspection functions. > > > -- > Martin > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

proposal: add 'unsafeCoerce'
by Malcolm Wallace 02 Apr '07

02 Apr '07

Currently, all implementations provide either the 'unsafeCoerce' or 'unsafeCoerce#' functions, but they live in implementation-specific locations. This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce', and to add it to the standard base library package. Suggested location: Data.Function.Unsafe? http://hackage.haskell.org/trac/ghc/ticket/994 Regards, Malcolm

17 45

System.Process bugs on Unix
by John Goerzen 02 Apr '07

02 Apr '07

I have another concern about System.Process. I have this code: (recordfn, recordh) <- openTempFile macdir "new-" ... (c1, macroh, c2, xmacroph) <- runInteractiveProcess "xmacrorec2" ["-k", "0xffff"] Nothing Nothing ... grepph <- runProcess "egrep" ["-v", "^(ButtonRelease|ButtonPress|MotionNotify)"] Nothing Nothing (Just macroh) (Just recordh) Nothing Now, egrep is dying with: grep: (standard input): Resource temporarily unavailable And strace shows that, sure enough, read(0,...) in grep is getting EAGAIN. Sounds like somebody forgot to take the fd out of non-blocking mode. This renders runProcess pretty well useless, IMHO. -- John

3 7

Dubious behavior in TH pretty printer
by Stefan O'Rear 02 Apr '07

02 Apr '07

The Template Haskell pretty-printer handles infix/prefix distinction improperly, causing text generated using it to be unparsable. Example: stefan@stefans:~/daanpp$ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7.20070323, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr Loading package template-haskell ... linking ... done. GHC.Num.+ 2 2 I am trying to use the Template Haskell AST system for internal representation of terms in a derivation library that can output Haskell or feed directly into a splice. This "bug", unfixed, would force me to fork the TH pretty printer. What would people think of a patch changing the behavor to "Always produce parsable output"? (Yes, I'm offering to implement it.) Stefan

3 4

Adding System.FilePath
by Neil Mitchell 02 Apr '07

02 Apr '07

Hi, When it comes to adding System.FilePath, we seem to have reached a concensus of indecision, so I am going to attempt to set out the various options, and see if we can pick one. 1) Do not let programmers type "import System.FilePath", i.e. do not include the module No one seems to be advocating this. 2) Let programmers type "import System.FilePath" and have it work in Cabal Setup.hs files, and in all Cabal built programs without requiring the user specify that they are using the filepath package. This is what everyone wants. Within this there are two approaches being advocated: a) Add to base. b) Add as a library which we demand all Haskell compilers ship, and tweak Cabal to automatically use this library at all times. Option a involves absolutely no additional work for me - the patch has been posted to this mailing list. Option b involves Cabal hacking, establishing new procedures, coming up with a definition of libraries which are always available etc. It is likely that option b will be required once (if ever) base is split up. I certainly don't have time to do option b. So can I propose we add filepath, with this agreement that once (someone else) gets around to doing option b, we can split it out afterwards? The particular argument for upgrading the filepath library I think is not important - I never intend to do more filepath hacking. Someone might add one or two functions, but thats about the most I can invision. It's not a particularly pleasant job, its ugly - the only reason I started this was because the alternative is having everything broken on Windows - something I do care about. Thanks Neil

15 73

darcs patch: Create showName, which takes an addition... (and 4 more)
by Stefan O'Rear 02 Apr '07

02 Apr '07

Adds support for handling prefix and infix names to the (Template Haskell) pretty printer; parenthesis and backticks are added as needed to match the intrinsic fixity of symbols with fixity contexts. Also contains a one-line fix causing irrefutable patterns to be properly printed. NB: changes Show Name output. Sun Apr 1 09:46:35 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Create showName, which takes an additional prefix-context argument Sun Apr 1 09:48:14 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Thread prefix-context argument through pprName Sun Apr 1 09:56:55 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Use pprName False in pretty printer Sun Apr 1 09:59:45 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Typo fixes, missing {in,ex}ports Sun Apr 1 12:02:15 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Properly handle tilde-patterns

1 0

Why the Prelude must die
by Stefan O'Rear 01 Apr '07

01 Apr '07

This is a ranty request for comments, and the more replies the better. 1. Namespace pollution The Prelude uses many simple and obvious names. Most programs don't use the whole Prelude, so names that aren't needed take up namespace with no benefit. 2. Monomorphism The Prelude defines many data types (e.g Lists), and operations on these types. Because the Prelude is imported automatically, programmers are encouraged to write their programs in terms of non-overloaded operators. These programs then fail to generalize. This is a highly non-academic concern. Many widely used libraries, such as Parsec, operate only on lists and not the newer and more efficient sequence types, such as bytestrings. 3. Supports obsolete programming styles The Prelude uses, and by means of type classes encourages, obsolete and naive programming styles. By providing short functions such as nub automatically while forcing imports to use sets, the Prelude insidiously motivates programmers to treat lists as if they were sets, maps, etc. This makes Haskell programs even slower than the inherent highlevelness of laziness requires; real programs use nub and pay dearly. More damagingly, the Prelude encourages programmers to use backtracking parsers. Moore's law can save you from nub, but it will never clarify "Prelude.read: no parse". 4. Stagnation Because every program uses the Prelude, every program depends on the Prelude. Nobody will willingly propose to alter it. (This is of course Bad; I hope Haskell' will take the fleeting opportunity to break to loop) 5. Inflexibility Because of Haskell's early binding, the Prelude always uses the implementation of modules that exists where the Prelude was compiled. You cannot replace modules with better ones. 6. Dependency Because every module imports the Prelude every module that the Prelude depends on, mutually depends with the Prelude. This creates huge dependency groups and general nightmares for library maintainers. 7. Monolithicity Every module the Prelude uses MUST be in base. Even if packages could be mutually recursive, it would be very difficult to upgrade any of the Prelude's codependents. 8. Monolithic itself Because the Prelude handles virtually everything, it is very large and cannot be upgraded or replaced piecemeal. Old and new prelude parts cannot coexist. 9. One-size-fits-all-ism Because the Prelude must satisfy everyone, it cannot be powerful, because doing so would harm error messages. Many desirable features of Haskell, such as overloaded map, have been abandoned because the Prelude needed to provide crutches for newbies. 10. Portability Because the Prelude must be available everywhere, it is forced to use only least-common-denominator features in its interface. Monad and Functor use constructor classes, even though MPTC/FD is usefully far more flexible. The Class_system_extension_proposal, while IMO extremely well designed and capable of alleviating most of our class hierarchy woes, cannot be adopted. 11. Committeeism Because the Prelude has such a wide audience, a strong committee effect exists on any change to it. This is the worst kind of committeeism, and impedes real progress while polluting the Prelude with little-used features such as fail in Monad (as opposed to MonadZero) and until. 12. There is no escape Any technical defect in Map could be fixed by someone writing a better Map; this has happened, and the result has been accepted. Defects in the PackedString library have been fixed, with the creation and adoption of ByteString. Defects in System.Time have been fixed, by the creation and adoption of Data.Time. Ditto for Binary and Arrays and Network and Regex. But this will never happen for the Prelude. A replacement Prelude cannot be adopted because it is so easy to take the implicit import of the default one. Nobody will go out of their way to 'import Prelude() ; import FixedPrelude'. Psychology trumps engineering. 13. There can be no escape The Prelude was designed by extremely smart people and was considered close to perfect at the time. It is almost universally hated now. Even if all the issues I describe could be fixed (which I consider unlikely), the Prelude will almost certainly be hated just as universally five years hence. 14. My future Given all these issues, I consider the only reasonable option is to discard the Prelude entirely. There will be no magic modules. Everything will be an ordinary library. HOFs like (.) are available from Control.Function. List ops come from Data.List. Any general abstractions can be added in abstract Sequence, Monad, etc. modules. Haskell will regain the kind of organic evolution whose lack currently causes Haskell to lose its lead over Python et al by the day. Stefan

15 22

Re: Can we do better than duplicate APIs? [was: Data.CompactString 0.3]
by Benjamin Franksen 01 Apr '07

01 Apr '07

Jean-Philippe Bernardy wrote: > Please look at http://darcs.haskell.org/packages/collections/doc/html/Data-Collections.html > for an effort to make most common operation on bulk types fit in a > single framework. The last time I looked at this (shortly after you started the project) I wasn't sure if I would want to use it. Now it seems like an oasis in a desert to me. I am pretty much impressed, for instance, you managed to unify all the nine existing 'filter' types into a common type class. Cool. The only hair in the (otherwise very tasty) soup is "Portability: MPTC, FD, undecidable instances" which doesn't sound like it is going to replace the Prelude any time soon ;-) Never mind: I definitely consider using this instead of importing all these different Data.XYZ modules directly (and, heaven forbid, having to import them qualified whenever I need two of them in the same module). Do you forsee any particular obstacle to an integration (=providing the appropriate instances) of e.g. CompactStrings? I would even try to do this myself, as an exercise of sorts. How difficult is it in practice to work with 'undecidable instances'? Are there special traps one has to be careful to walk around? > Also, we expect indexed types to solve, or at least alleviate, some > problems you mention in your "rant". > http://haskell.org/haskellwiki/GHC/Indexed_types I have been hoping for that to resolve (some of) our troubles, but have been confused by the all the back and forth among the experts about whether they offer more, or less, or the same, as MPTCs+fundeps+whatever (and that they will probably not go into Haskell'). BTW, any reason I didn't find your collections library in the HackageDB (other than stupidity on my part)? (Just interested, I already found the darcs repo.) Cheers Ben PS: Since I read and post to the Haskell lists via gmane and a news client: Do mail clients usually respect the follow-up header, such as I insert when cross-posting, so as to restrict follow-ups to the intended list?

3 4

[Fwd: updateLookupWithKey confusion]
by Adrian Hey 01 Apr '07

01 Apr '07

Hello Folks, Jean-Philippe suggests I put this question to the libraries list. Any thoughts? -------- Original Message -------- Subject: updateLookupWithKey confusion Date: Mon, 26 Mar 2007 08:18:47 +0100 From: Adrian Hey <ahey(a)iee.org> To: Jean-Philippe Bernardy <jeanphilippe.bernardy(a)gmail.com> Hello Jean-Philippe, There seems to be some confusion over this between Haddock documentation and the two implementations in Data.Map and Data.Map.AVL. Is the 'looked up' value supposed to be the value bound to the corresponding key in the map before or after the update? The behaviour isn't specified in the Haddock of either version. In Data.Map implementation you could get the value present before or after the update (depending on whether or not the association is deleted). Surely that's wrong? In Data.Map.AVL you consistently get the value present before the update occurs, but I would have thought it be more useful to get the value after the update occurs (if any). Anyway, I think the behaviour needs specifiying and whichever implementation(s) is not consistent with that spec needs modifying. I'm working on Data.Map.AVL at the moment so I'll fix it if it's wrong (and make it more efficient too). Also, why don't we have a plain updateLookup? (without key), like we do for other funcions. Regards -- Adrian Hey

2 3

darcs patch: Turn off _SERVER64 and correct type of state field in ...
by Chris Mears 30 Mar '07

30 Mar '07

Fri Mar 30 07:14:05 EST 2007 Chris Mears <chris(a)cmears.id.au> * Turn off _SERVER64 and correct type of state field in Event structs. _SERVER64 should be defined only for compiling X server code, so we shouldn't use it here. Changed the type of the "state" member in the XKeyEvent, XButtonEvent and XMotionEvent structures from Modifier to CUInt. This now matches the type given in the X11 header files.

3 2