Are Records stalled out again? I am perfectly willing to leave the fate of
records up to a willing and capable implementer. That seems much better than
waiting another 5 years for perfection :)
Yes, they are stalled again. The "simple solution" turned out to be not
simple. I wrote it up at length in
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
There are various unsatisfactory aspects of the proposal, particularly
concerning record update. I am not sure how to resolve them.
There was essentially no reaction. As it's quite a lot of work to implement,
and no one seemed to care very much, I put it back on the back burner. So
that's where it stands.
Meanwhile, AntC has put forth another proposal that I have not had time to look
at in detail.
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html
What this needs is someone (not me) to lead the discussion and try to make sure
it makes progress. For example, does AntC's proposal work? Is it better than
the one I articulated? Are any other variants worth considering? Is the gain
from overloading record fields worth the pain or design and implementation?
Volunteers, stand forth!
Simon
From: Greg Weber [mailto:g...@gregweber.info]
Sent: 09 December 2011 19:38
To: Simon Peyton-Jones
Cc: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
Are Records stalled out again? I am perfectly willing to leave the fate of
records up to a willing and capable implementer. That seems much better than
waiting another 5 years for perfection :)
As an intermediate step, is it possible to put a warning in 7.4 when the dot
operator is used without a space so that it can be reserved for usage with a
records solution? Or will the new records solution be turned on by an extension
anyways?
On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones
<simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote:
| would inclusion of such a record system into GHC mean that plans for
| first-class labels (<http://tinyurl.com/7fppj32>) are abandoned? That
| would be a pity, since first-class labels are very useful to implement
| record systems that go beyond what the abovementioned record system
| provides. See, for example, my work on records:
|
<http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf>
| <http://hackage.haskell.org/package/records>
The story is summarised at
http://hackage.haskell.org/trac/ghc/wiki/Records
First-class labels are one point in the vast swamp of competing and overlapping
proposals for records. I think they are summarise here:
http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords
I am unsure which of this list of proposals you are referring to. The URL you
quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
but it doesn't seem to actually contain a design, merely some options for a
design that is implicit. If you do have a design you advocate, it would be
good to add it to the list at
http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords
perhaps explaining which of the other members of the list it subsumes.
Because there are so many proposals I have not gone ahead with any of them.
The most recent thread, articulated at
http://hackage.haskell.org/trac/ghc/wiki/Records
is to ask what is the *smallest change* that would solve the *most pressing
problem*, namely the inability to use the same field name in different records.
First class labels is (I assume) much more ambitious. But maybe not.
Anything you can do to bring clarity to the swamp, by editing the above two
pages, would be a great service to the community. At the moment, we are stuck
in an infinite loop.
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
