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 <g...@gregweber.info> 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 > <jerzy.karczmarc...@unicaen.fr> 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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users