March 2007 - Libraries

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 31 Mar '07

31 Mar '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 29 Mar '07

29 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

darcs patch: Changing Int to CInt and building with -D_XSERVER64 (w...
by thedward＠antejentacular.org 29 Mar '07

29 Mar '07

Wed Mar 28 01:24:53 CDT 2007 thedward(a)antejentacular.org * (Graphics.X11) Updates for (better) 64-bit compatibility Changing Int to CInt and building with -D_XSERVER64 (when appropriate) I went through and weeded out all the Ints I could find, replacing them with CInts, adding fromIntegral calls as necessary. I modified configure.ac and X11.buildinfo.in to support detecting 64-bit systems. (inspired by the test in the xorg build). All these changes seem to make X11 much more useful on 64-bit systems. Most importantly, I've got xmonad up and running beautifully.

6 7

Proposal: Add First and Last wrappers around Maybe to Data.Monoid
by Jeffrey Yasskin 29 Mar '07

29 Mar '07

I've created http://hackage.haskell.org/trac/ghc/ticket/1189 to suggest adding two Monoid instances around Maybe that, instead of accumulating things like most monoids, just pick the first or last piece of data they see. Would a week (March 12) be enough time to discuss this? Thanks, Jeffrey Yasskin

7 12

darcs patch: (X11.Graphics) More Int -> CInt cleanup ; Will break e...
by thedward＠antejentacular.org 29 Mar '07

29 Mar '07

Wed Mar 28 20:05:33 CDT 2007 thedward(a)antejentacular.org * (X11.Graphics) More Int -> CInt cleanup ; Will break existing programs. This patch takes care of the rest of the Int usages. These changes break API compatibility. Existing programs will likely require (minor[1]) changes to compile once these changes are applied. [1]Mostly just switching from Int to CInt or using fromIntegral as appropriate.

2 1

Re: Re: Why the Prelude must die
by Benjamin Franksen 28 Mar '07

28 Mar '07

Nicolas Frisby wrote: > Regarding type variable naming, a few of my more hardware minded > friends I've asked to try Haskell often tease me about the opaque type > variable names in the Prelude--it seems greater consideration of type > variable names in the Prelude might behoove new users. I think that single letter names are very a good idea for most of the things in the Prelude. 'a', 'b' etc. are good for very general things like the basic classes (Eq, Num, etc) and for parametric functions (flip, (.), etc). I also like the 'm' for Monads of all kinds, but I would suggest to use 'mt' for monad transformers. For collections I think 'c' is nice and 'k' for keys seems to be sort of standard, but I would like to propose using 'e' as generic name for elements of collections, if there are more element types, then 'e1', e2' etc. There are more complicated cases where a multi-letter name seems apropriate, but there appear to me none of them in the Prelude. Cheers Ben

1 0

Control.Monad.Cont documentation
by Andriy Palamarchuk 28 Mar '07

28 Mar '07

Documentation for the Continuation monad. Right now this module does not have any haddock comments. Per Jeff Newbern's gracious permission included relevant information from his cool tutorial "All About Monads" http://www.nomaware.com/monads/, created a couple of examples. The source of the module and haddock output for it are attached to the ticket: http://hackage.haskell.org/trac/ghc/ticket/1169 Here is the generated haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1169/Control-Monad-Co… Deadline for the proposal - 2 weeks. Questions, comments, suggestions? Andriy Palamarchuk ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited

3 2

Re: [Haskell-cafe] Re: Why the Prelude must die
by Arthur van Leeuwen 27 Mar '07

27 Mar '07

On 27-mrt-2007, at 20:17, Nicolas Frisby wrote: > Gut feeling: the quick'n dirty script case occurs far less than the > whole module case. Thus I think the benefit of automatically importing > the Prelude if the module declaration is omitted should not happen: > the Principle of Least Surprise out-weighs the small benefit to a rare > case. In my experience quick'n'dirty scripts tend to end up as full-blown modules later on in their life. This, to me, is a strong indication to make importing the prelude explicit. Furthermore, the arguments against explicit importing seem to be easier teaching and shorter code, as one needs much of the Prelude almost everywhere. However, Java seems to offer a reasonable datapoint in this argument: almost everything in the language needs to be explicitly imported, but for java.lang. Ofcourse, java.lang is quite annoyingly big... so a good example it is not. > Regarding type variable naming, a few of my more hardware minded > friends I've asked to try Haskell often tease me about the opaque type > variable names in the Prelude--it seems greater consideration of type > variable names in the Prelude might behoove new users. Good point. It would also make the Prelude sources (and Haddock docs) *much* easier to understand. Doei, Arthur. -- /\ / | arthurvl(a)cs.uu.nl | 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

1 0