Re: Records in Haskell

On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones wrote:

Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. Lets just start by using Frege's document as the proposal. We can start a new wiki page as discussions are needed.****

** **

If it’s a serious proposal, it needs a page to specify the design. Currently all we have is a paragraph on http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name spacing”.****

** **

As previously stated on this thread, the Frege user manual is available here:****

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

see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields)****

** **

To all those concerned about Records: look at the Frege implementation and poke holes in it. ****

** **

Well the most obvious issue is this. 3.2 says ****

*e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type constructor****

of *t *is *T *and there exists a function *T*.*m*

But that innocent-looking statement begs the **entire** question! How do we know if “e has type t? This is the route ML takes for arithmetic operators: + means integer plus if the argument is of type Int, float plus if the argument is of type Float, and so on.

****

** **

Haskell type classes were specifically designed to address this situation. And if you apply type classes to the record situation, I think you end up with****

http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields

More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation.

****

** **

Well, so maybe we can give up on that. Imagine Frege without the above abbreviation. The basic idea is that field names are rendered unique by pre-pending the module name. As I understand it, to record selection one would then be forced to write (T.m e), to select the ‘m’ field. That is the, qualification with T is compulsory. The trouble with this is that it’s **already** possible; simply define suitably named fields****

data T = MkE { t_m :: Int, t_n :: Bool }****

Here I have prefixed with a (lower case version of) the type name. So we don’t seem to be much further ahead.****

** **

Maybe one could make it optional if there is no ambiguity, much like Haskell’s existing qualified names. But there is considerable ambiguity about whether T.m means ****

m imported from module T****

or****

the m record selector of data type T

If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T's module: OtherModule.T.n or T.T.n Alternatively these conflicts could be compilation errors. Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now. ****

** **

Perhaps one could make it work out. But before we can talk about it we need to see a design. Which takes us back to the question of leadership.** **

I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort. At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don't have convenient access to those fields. I am contacting the Frege author to see if we can get any more insights on implementation details.

Simon****

** **

** **

We only want critiques about****

* achieving name-spacing right now****

* implementing it in such a way that extensible records could be implemented in its place in the future, although we will not allow that discussion to hold up a records implementation now, just possibly modify things slightly.****

** **

Greg Weber****

** **

On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones wrote:****

| The lack of response, I believe, is just a lack of anyone who | can cut through all the noise and come up with some | practical way to move forward in one of the many possible | directions.****

You're right. But it is very telling that the vast majority of responses on

http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leaders... were not about the subject (leadership) but rather on suggesting yet more, incompletely-specified solutions to the original problem. My modest attempt to build a consensus by articulating the simplest solution I could think of, manifestly failed.

The trouble is that I just don't have the bandwidth (or, if I'm honest, the motivation) to drive this through to a conclusion. And if no one else does either, perhaps it isn't *that* important to anyone. That said, it clearly is *somewhat* important to a lot of people, so doing nothing isn't very satisfactory either.

Usually I feel I know how to move forward, but here I don't.

Simon

****

** **