Records in Haskell

Tue Dec 27 12:32:11 CET 2011

The original goal was to come up with a simple solution. Perhaps that goal
is unattainable, or at least attaining it has much higher cost than we had
hoped. If that is the case we must take a step back and look at changing
how things are done currently. Perhaps the approach that a record label
becomes a global module function is just not feasible.

In the Frege <http://code.google.com/p/frege> (a Haskell with some
differences implementation on the JVM) language every data type is at the
same time a namespace.

* the function that accesses field x of data type T is T.x

* If a::T then a.x = T.x a

* the function that updates field x of data type T is T.{x=}

* the function that sets field x in a T to 42 is T.{x=42}

* If a::T then a.{x=} and a.{x=42} are valid

* the function that changes field x of a T by applying some function to it
is T.{x <-}

* T.{x?} is a function that returns true iff the argument was constructed
with a data constructor that has field x.
In the Opa language a Module is in fact a Record specially marked as a
module.

What do you think of the Frege system?

On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber <greg at gregweber.info> wrote:

> I am willing to help on this as much as I can. Unfortunately I don't think
> you want me to lead the discussion or make decisions on this - many of
> these discussions seem over my head. I will continue to study them though
> and see if the sink in more.
>
> I do think almost all of these proposals want a dot selector, so it is a
> good idea for Haskell to require the normal function (composition) dot to
> have spaces around it - should this be brought to the Haskell
> Prime committee?
>
> Greg Weber
>
>
> On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones <simonpj at microsoft.com
> > wrote:
>
>>  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:greg at gregweber.info]
>> *Sent:* 09 December 2011 19:38
>> *To:* Simon Peyton-Jones
>> *Cc:* Wolfgang Jeltsch; glasgow-haskell-users at 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 <
>> simonpj at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users****
>>
>> ** **
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20111227/ea85068b/attachment.htm>