Re: Records in Haskell

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 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 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@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.... ****

** **

*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@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 < simonpj@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 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users****

** **