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
