Records in Haskell

Wed Dec 28 14:05:30 CET 2011

The semantics of Frege's records are layed out in its manual [1] in the
following sections:
4.2.1 Algebraic Data type Declaration - Constructors with labeled fields
3.2 Primary Expression

The Frege record system explanation is the first one that I could read and
immediately understand (oh, it just creates a namespace!). Perhaps this is
just in part because it was better explained. But I think it is also
because desugaring records to a library is a very complicated proposition,
whereas taking the same library concept but baking it into the compiler and
making simple language modifications is actually much more straightforward
to understand.

Many of the built-in record proposals seem more ambitious (create a new
record from an existing one, generalize in some other direction). More
power or generalization could be very useful, but it can wait for later -
Haskell's records are glaringly bad because they lack name-spacing.

I think one of the problems being faced with improving records is a false
choice between a quick but hacky library desugaring or a major "Extensible"
records built into the compiler. What I am proposing is that (unless
someone proposes a great desugaring solution) we make it the immediate goal
to have records built into the compiler, but done in the simplest (perhaps
least "Extensible") way that just accomplishes name-spacing.

[1] http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf

On Tue, Dec 27, 2011 at 8:32 AM, Greg Weber <greg at gregweber.info> wrote:

> 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/20111228/6aede342/attachment-0001.htm>