Simon Peyton-Jones
writes:
> | Proposal: FirstClassFieldUpdates
> |
> | Summary: Add some syntax that makes field updates into
> | functions.
>
> I'm wary about occupying too much "syntactic space" with
> Haskell's named-field notation. If you had a keyword, like
> update { foo = bar } meaning \
| Proposal: FirstClassFieldUpdates
|
| Summary:
| Add some syntax that makes field updates into functions.
I'm wary about occupying too much "syntactic space" with Haskell's named-field
notation. If you had a keyword, like
update { foo = bar }
meaning
\x. x { foo = bar }
that'd
Jon Fairbairn wrote:
Isaac Dupree
writes:
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
Hi all,
Jon Fairbairn wrote:
> Isaac Dupree wrote:
> >
> > 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
Isaac Dupree
writes:
> 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
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