- Libraries - Haskell.org

Proposal: reduce base from the top
by Simon Marlow 06 Apr '07

06 Apr '07

This is an attempt to propose a set of changes that we could reasonably make in the GHC 6.8 timeframe, that would significantly reduce the size of base and give us more flexibility to independently develop packages. This is not an attempt to solve all the issues we have in one go, but a practical incremental step towards the goal. I'm not trying to make base compiler-independent for example; that's a worthy goal, but it's not clear (at least to me) how to get there yet. What I'm doing here is disentangling the dependencies from the top down. We started on this path before GHC 6.6 (see http://hackage.haskell.org/trac/ghc/ticket/710) this proposal will clarify some the details of the next stage. There may be dependencies I've missed, but as far as I'm aware all of the following is possible without any significant rewriting of code. These reoganisations will allow more reuse: for example, more libraries will be able to make direct use of the unix/Win32 packages rather than being limited to the primitives available in the base package, so cleanups will be possible after the reoganisation. There are several things I'm not completely sure about, and some naming issues to resolve, so please take a look and comment if you can. I'll make one request regarding comments: please don't suggest renaming modules at this point. There are various modules whose names I'm aware are contentious, but I think it would be a distraction to discuss those as part of this proposal; let's do it separately. Here goes: System.Time --> new package old-time (dep. on unix/Win32) System.Locale --> new package old-locale System.Posix.Signals --> unix (System.Cmd depends on it, but moves to new package process) System.Directory --> new package directory (dep. on filepath, unix/Win32) System.Directory.Internals goes away, use filepath instead Data.Array.* --> new package array (maybe; I'm slightly dubious here) (dep. on concurrent for Data.Array.Diff) Data.Generics.* --> generics (maybe; Data class is defined for everything and is derivable) Data.ByteString.* --> fps (dep. on base, generics, array) Control.Concurrent.*, System.Timeout --> new package concurrent (needed by Data.Unique, where to move it?) Control.Parallel.* --> new package parallel System.Process, System.Cmd --> new package process (dep. on concurrent) Control.Applicative Data.Foldable, Data.Traversable Data.Map, Data.IntMap, Data.Set, Data.IntSet Data.Sequence, Data.Tree Data.HashTable Data.Graph ---> new package collections? containers? or split further? (dep. on array, generics, concurrent) System.Console.GetOpt ---> new package getopt? consoleutils? Text.PrettyPrint.* ---> new package pretty System.Random ---> new package random (modify to use time, not old-time) Other modules we could move: Text.Printf, Data.Unique, Data.Monoid, System.CPUTime. Topological sort of core packages with dependencies --------------------------------------------------- base unix/Win32 (base) generics (base) concurrent (base) parallel (base) filepath (base) Cabal (base) readline (base) regex-base (base) regex-posix (base, regex-base) regex-compat (base, regex-base, regex-posix) parsec (base) stm (base) template-haskell (base) pretty (base) (could drop from core-packages) getopt (base) (could drop from core-packages) old-locale (base) old-time (base, unix/Win32) array (base, generics, concurrent) fps (base, generics, array) process (base, unix/Win32, concurrent) directory (base, unix/Win32, filepath) time (base, unix/Win32) random (base, unix/Win32, time) haskell98 (old-time, old-locale, random, directory, process) containers (base, array, generics, concurrent)

10 14

darcs patch: Fix precedence passing for patterns in L... (and 1 more)
by Stefan O'Rear 05 Apr '07

05 Apr '07

Testing = typechecked Mon Apr 2 08:26:34 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Fix precedence passing for patterns in LamE (fixes \((:) x xs) -> x misprinting) Mon Apr 2 08:28:54 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Pretty-print an empty list of fundeps without '|' (should fix #1260)

2 1

System.Posix.User.getAllUserEntries bugfix
by Pixel 03 Apr '07

03 Apr '07

it seems setpwent is never called, and so getAllUserEntries can only be used once. Here is a suggested fix: (if i should be posting this somewhere else (a bug system...), please tell me)

1 0

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 01 Apr '07

01 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