July 2009 - Haskell-prime

Announcing the new Haskell Prime process, and Haskell 2010
by Simon Marlow 20 Aug '09

20 Aug '09

At last year's Haskell Symposium, it was announced that we would change the Haskell Prime process to make it less monolithic. Since then, everyone has been busy using Haskell (or implementing it), and we haven't made much progress on the standardisation side of things. Well, with ICFP and the Haskell Symposium approaching we felt it was time to get the new process moving and hopefully produce a language revision this year. I've updated the Haskell' wiki with the new information; in particular the process is documented here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process We're aiming to announce the list of accepted proposals at the Haskell Symposium this year. However, owing to the short timescale, the list is going to be correspondingly short, and limited to extensions which are either already fully specified (i.e. the FFI) or are small and well-understood. The following list is very provisional; we'll be making the final decisions next month. ForeignFunctionInterface LineCommentSyntax PatternGuards DoAndIfThenElse Remove n+k patterns RelaxedDependencyAnalysis EmptyDataDeclarations HierarchicalModules NonDecreasingIndentation remove FixityResolution from the context-free grammar change the syntax of QualifiedOperators In the coming weeks we'll be refining proposals in preparation for Haskell 2010. By all means suggest more possibilities; however note that as per the new process, a proposal must be "complete" (i.e. in the form of an addendum) in order to be a candidate for acceptance. I have updated the status page http://hackage.haskell.org/trac/haskell-prime/wiki/Status marking everything except the proposals that have been already implemented in the draft Report as "old". The new process requires a proposal to have an owner or owners in order to make progress; once a proposal has an owner it will move into the "under discussion" state. To take up ownership of an existing proposal, or to start a new proposal, ask on the mailing list. There are other ways you can get involved; some suggestions are on the Haskell' main page: http://hackage.haskell.org/trac/haskell-prime/wiki (hmm, I suppose we should fix that logo too...) Cheers, Simon

16 35

StricterLabelledFieldSyntax
by Ian Lynagh 15 Aug '09

15 Aug '09

Hi all, I've made a ticket and proposal page for making the labelled field syntax stricter, e.g. making this illegal: data A = A {x :: Int} y :: Maybe A y = Just A {x = 5} and requiring this instead: data A = A {x :: Int} y :: Maybe A y = Just (A {x = 5}) http://hackage.haskell.org/trac/haskell-prime/ticket/132 http://hackage.haskell.org/trac/haskell-prime/wiki/StricterLabelledFieldSyn… Thanks Ian

13 34

NoMonomorphismRestriction
by Ian Lynagh 07 Aug '09

07 Aug '09

Hi all, I've made a ticket and proposal page for removing the monomorphism restriction: http://hackage.haskell.org/trac/haskell-prime/ticket/131 http://hackage.haskell.org/trac/haskell-prime/wiki/NoMonomorphismRestriction Thanks Ian

6 6

Haskell 2010: libraries
by Simon Marlow 27 Jul '09

27 Jul '09

This is more of a consistency issue than anything else. We have to decide what to do with the libraries in the Report. Right now, the Haskell Report specifies 15 library modules. Things like Maybe, Char, IO, Time, and Random. The situation is not ideal, for many reasons: - There are a lot more than 15 library modules available to Haskell programmers! The libraries section of the report was a good idea when there were no libraries at all, nowadays it makes a lot less sense. - These modules are using the old non-hierarchical names. Best practice these days is to use the hierarchical versions. - some of these libraries have well-known problems, and some have been superseded by better libraries: Time is a good example. On the other hand, some people like having these modules around, and deliberately use them because they aren't allowed to change. I'm mainly concerned with projecting a consistent picture in the Report, so as not to mislead or confuse people. Here are the options I can see: 1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however. There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary. 2. Just drop the obvious candidates (Time, Random, CPUTime, Locale, Complex?), leaving the others. 3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. Also it would seem slightly strange to have a seemingly random set of library modules in the report. 4. Combine 2 and 3: drop some, rename the rest. 5. Don't do anything. Note that we have to take into account the FFI libraries too: the FFI addendum includes modules such as Foreign, CForeign, Storable, MarshalError, and so on. The same issues apply: the report needs to mention some of the types and entities exported by these modules. I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation. Please keep discussion focussed: this is about how libraries are presented in the Haskell report, not about library standardisation in general. I'm aware there are much wider issues, but we have some immediate problems to address. Cheers, Simon

15 49

ExplicitForall
by Niklas Broberg 27 Jul '09

27 Jul '09

Hi all, Per request I've made a ticket and proposal page for adding ExplicitForall to Haskell'2010: http://hackage.haskell.org/trac/haskell-prime/ticket/133 http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall Cheers, /Niklas

1 0

NoNPlusKPatterns
by Ian Lynagh 27 Jul '09

27 Jul '09

Hi all, I've made a ticket and proposal page for removing n+k patterns: http://hackage.haskell.org/trac/haskell-prime/ticket/130 http://hackage.haskell.org/trac/haskell-prime/wiki/NoNPlusKPatterns Should I have also added it to some index page somewhere? Please let me know if there's anything else I should do. By the way, I find all the old tickets and wiki pages make it very hard to understand what is current on the haskell-prime trac. Thanks Ian

2 1

patch applied (haskell-prime-report): Tweak rule so make knows how to create haskell.idx
by Ian Lynagh 24 Jul '09

24 Jul '09

Tue Jul 21 04:06:30 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Tweak rule so make knows how to create haskell.idx M ./report/Makefile -1 +1 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721110630…

1 0

patch applied (haskell-prime-report): Refactor away old-fashioned make syntax
by Ian Lynagh 24 Jul '09

24 Jul '09

Tue Jul 21 04:03:50 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Refactor away old-fashioned make syntax M ./report/Makefile -7 +5 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721110350…

1 0

patch applied (haskell-prime-report): Remove duplicate haskell.dvi dependencies
by Ian Lynagh 24 Jul '09

24 Jul '09

Tue Jul 21 03:47:49 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Remove duplicate haskell.dvi dependencies M ./report/Makefile -2 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721104749…

1 0

patch applied (haskell-prime-report): Everyone has perl, clean Prelude*.tex too
by Ian Lynagh 24 Jul '09

24 Jul '09

Tue Jul 21 03:39:57 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Everyone has perl, clean Prelude*.tex too M ./report/Makefile -3 +1 View patch online: http://darcs.haskell.org/haskell-prime-report/_darcs/patches/20090721103957…

1 0