RE: StricterLabelledFieldSyntax
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
teaching Haskell syntax to newbies; the simple rule juxtaposition binds
tighter than everything else doesn't quite work.
Ganesh
===
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: StricterLabelledFieldSyntax
Neil Mitchell ndmitch...@gmail.com
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 clearer) is a good thing.
I haven't seen anyone else claim to use the current more liberal
syntax for fields, but I know that I do rather extensively. I would
consider:
Just A {a = 1}
To be confusing, but if you simply omit the space:
Just A{a = 1}
I now find that perfectly clear and unambiguous. I realise this isn't
necessarily a discussion of the merits of the feature, but I don't
consider this removal as clear cut as some people are suggesting.
for what it's worth, I do take advantage of the current syntax for
functions with default parameters:
f defaults{some_option = non_default_value}
and like you, I don't put a space. I've long thought that compilers
should issue warnings for layout that conflicts with precedence --
everyone knows that 2+2 * 8 means 2 + (2*8), but I'd guess it takes a
/tiny/ bit longer to read correctly, and for less familiar operators the
misleading layout is more likely a source of misreadings.
--
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Proposal: FirstClassFieldUpdates
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
m...@isaac.cedarswampstudios.org
writes:
Jon Fairbairn wrote:
Ian Lynagh ig...@earth.li writes:
[field update] /has/ the
binding level of function application. ie, instead of a{x=42} one would
have to write {x=42}a,
we already know which record type it is, because record
fields don't have disambiguation.
OK, I'd forgotten that. Makes things straightforward.
I think it wouldn't be a terrible syntax, ({...}), kind of
like infix operators can be made into functions like (+).
If you wanted to make a proposal for such an extension.
I was wondering how to make it compatible. That looks like a reasonable
compromise, so...
Proposal: FirstClassFieldUpdates
Summary:
Add some syntax that makes field updates into functions.
Description:
On several occasions I've wanted to pass arguments that modified records
and been disappointed that I have to use a lambda expression.
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. This chimes reasonably well with (+) turning an infix
operator into a function. ({}) would be the (polymorphic) identity
function.
This would permit concise calls to functions with default/optional
parameters:
data Defaults_for_f = Defaults_for_f {option1::A, option2::B, ...}
defaults_for_f = Defaults_for_f {option1=default1, ...}
f options other arguments = let params = options defaults_for_f in ...
allows one to write f ({}) ... (or f id ... if no-one likes ({})) to
call f with the default arguments, or f ({option1 = something_else}) ...
to go away from the defaults.
Discussion:
I would rather make {field1=a, field2=b, ...} a function. ie instead of
a{thing=1} one would write {thing=1} a. In other words {field1=a,
field2=b, ...} would be a notation for the function that is currently
written \d - d{field1=a, field2=b, ...}. Again we would want empty
record updates {} to be the identity function. We would then remove the
thing{fu=bar} syntax (where thing is a variable).
This would simultaneously simplify the syntax, remove the misleading f
x {a=b} bemoaned in StricterLabelledFieldSyntax and make certain use
cases (such as default parameters) more concise. Unfortunately old
programmes wouldn't compile any more¹, but I think that Haskell' is the
place for backwards incompatible changes that simplify things.
The difficulty would be what to do about Constructor{fu=bar}, given that
Constructor is currently defined to operate both as a function and be
used in patterns (there's something fishy about this when the record has
named fields). As yet I haven't thought of a good way of doing that,
hence the current proposal that adds syntax rather than takes it away.
[1] All the errors would be compile time errors.
--
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell'-private] NoMonomorphismRestriction
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 have to do http://hackage.haskell.org/trac/haskell-prime/wiki/SpecifyPatternBindingSemantics Which is not strictly speaking a change, but is a necessary clarification if the MR is removed. I believe the conclusion we came to in March/April 2008 was to do this. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell'-private] NoNPlusKPatterns
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 somewhere? Please let me know if there's anything else I should do. No, that's all you need to do. This link shows the proposals grouped by status, which shows the ones that are actively being worked on: http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedgroup=state (that link is available from the home page as All Proposal Tickets) 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. We could easily make the query ignore the old tickets. Would that help? Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
ExplicitForall
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: FirstClassFieldUpdates
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. Say,
data C nx ny = C { x :: nx, y :: ny }
x_set :: nx2 - C nx1 ny - C nx2 ny
--x_set x2 c = c {x = x2} --type error
--x_set x2 = ({x = x2}) --still a type error
x_set x2 c = C {x = x2, y = y c} --legal
Which is possibly a reason to stay away from field-update syntax on some
occasions, and therefore not want it to get a more prominent place in
the language if it doesn't deserve it yet.
-Isaac
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
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 was immortalised in the H98 report with
104 exports, Data.List has gained an additional 7 exports:
The last change (making the behaviour of the generic* functions
consistent with their non-generic counterparts) was less than a year
ago, and the last additions were less than 2.
Though also note that we have not changed any of the existing ones.
Yes we have, less than a year ago:
Also, we've just had a proposal to change some others:
Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
http://hackage.haskell.org/trac/ghc/ticket/3399
Both functions are spec in List in haskell98:
http://haskell.org/onlinereport/list.html
Thanks
Ian
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
