Re: Haskell 2010: libraries

2009-07-27 Thread Ian Lynagh
On Tue, Jul 14, 2009 at 01:57:34PM +0100, Ian Lynagh wrote: > On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: > > On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: > > > On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: > > > > > > > To take one example, since List w

Re: Proposal: FirstClassFieldUpdates

2009-07-27 Thread Isaac Dupree
Jon Fairbairn wrote: Parenthesis around updates would make them into functions, ie ({a=1,b=2,...}) would mean the same as (\d -> d{a=1,b=2,...}), but be more concise. yes it is, however field updates are occasionally slightly annoying, since they can't change something's type at all, IIRC. Sa

ExplicitForall

2009-07-27 Thread Niklas Broberg
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 ___ Haske

Re: [Haskell'-private] NoNPlusKPatterns

2009-07-27 Thread Simon Marlow
On 25/07/2009 02:02, Ian Lynagh wrote: 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 s

Re: [Haskell'-private] NoMonomorphismRestriction

2009-07-27 Thread Simon Marlow
On 25/07/2009 16:28, Ian Lynagh wrote: 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 I think if we do this we really hav

Proposal: FirstClassFieldUpdates

2009-07-27 Thread Jon Fairbairn
According to the wiki, since I'm not a committee member, I should post proposals here. See below my reply to Isaac's message. Isaac Dupree writes: > Jon Fairbairn wrote: >> Ian Lynagh writes: >> [field update] /has/ the >> binding level of function application. ie, instead of a{x=42} one would

Re: StricterLabelledFieldSyntax

2009-07-27 Thread Jon Fairbairn
Neil Mitchell writes: > Hi > >>> Would it be proper to create a counterproposal for this syntax? >>> ReversedLabelledFieldSyntax? >> >> I would claim that, of the existing Haskell code, >> StricterLabelledFieldSyntax only rejects unclear ("bad") code, and >> requiring it be changed (to be made cl

RE: StricterLabelledFieldSyntax

2009-07-27 Thread Sittampalam, Ganesh
Ian Lynagh wrote: > 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} +1: The precedence here is an ugly wart. It's particularly annoying when t