Re: Records in Haskell

Hi Greg, (Apologies for second mail, I didn't include the list) I think the DORF approach is quite principled in it's namespacing. The labels are just normal functions which can be exported and imported between modules. I believe that is it's main strength - so I think to say "it only solves the narrow name-spacing issue within a module." is not quite accurate. Sure - if you have two unrelated modules - say Data.Foo and Data.Bar each with records with fields x and y they will clash. But this is a very common situation e.g. how many functions called "map" are defined in various modules? If the modules are related, however - we can re-use the same label without problem (in the same way we can define a type class Functor for all the various "map" functions). I don't think it is so important that we have globally common labels - if anything I would think that would be an engineering goal to avoid? (Imagine how many labels called "x" with different types may spring up) -- First you create the labels: module A (width, height) width :: r { width :: Float } => r -> Float height d :: r { height :: Float } => r -> Float -- We can use them in one module. module B (Rectangle (..)) where import A (width, height) data Rectangle = Rectangle { width, height } -- Potentially don't need to give these types, since they're already defined by the label module C (Box (..)) where import A (width, height) length d :: r { length :: Float } => r -> Float data Box = Box { width, height, length } -- Use the same fields again I've been following the discussion with interest. Cheers, Oliver On Mon, Feb 27, 2012 at 5:47 AM, Greg Weber wrote:

The DORF proposal is bringing to light some universal issues with records, so I am glad they are being hashed out. However, at this point it is premature optimization: we still don't have a proposal that solves the narrow issue of record name-spacing with Haskell.

At this point SORF/DORF need a hero to figure out how to make them work with all of Haskell's current type capabilities. The DORF proposal makes some steps forward, but also backwards: it only solves the narrow name-spacing issue within a module. If a record is imported into another module, it will still clash.

I stated this months ago, and I think it is even truer now: the sugar approach to records does not appear to actually be simplifying things, therefore we should consider adding a new first-class construct.

I don't know much about the subject of first-class records, but so far I have come across a few styles of existing implementations in FP: structural typing, records as modules, and row types. I recently linked to Ur's extensible record impementation (that uses row types) from the wiki: http://adam.chlipala.net/papers/UrPLDI10/UrPLDI10.pdf

We are trying to stay focused on the narrow issue of solving name-spacing. I think we can stay narrow if we do implement first class records but hold off for now on presenting any special capabilities to the programmer.

At this point we are months into the records process without a clear way forward. I think we should be willing to take any workable implementation and just avoid exposing the implementation details for now. If anyone can lend a hand at figuring out SORF updates or determining if type inference of records in the Ur paper can be made to work in Haskell, that would be very helpful!

Greg Weber

On Sun, Feb 26, 2012 at 7:01 AM, Jerzy Karczmarczuk wrote:

...

Barney Hilken :

...

Haskel is supposed to be a theoretically sound, cleanly designed language, and if we lose sight of this we might as well use C++.

Well, since I have nothing to say about new records, I don't say anything, but I have the impression that when we got to this level of discussion, it is a beginning of the end. Veeery, very funny...

Imagine an ecclesiastic General Council, and the Pope saying:

"Brothers Bishops! Our new dogmas must be absolutely flawless, pure and sound, otherwise we might as well become Muslims".

Inchaa whatever.

Jerzy Karczmarczuk Caen, France

_______________________________________________ Glasgow-haskell-users mailing list 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