Re: Records in Haskell
Whoa! suddenly a deluge over the DORF proposal. I don't have time to reply fully now, but I must say: Barney you have got it all wrong. No, DORF does not attach one class to each label. There is only one class 'Has', with methods get and set. Each record decl generates an instance for the combination of record/field. You can't mix declared and free-standing labels in the same record. The switch for DORF is at the module level: in a module either all records and labels use DORF, or none do (that is, they use H98 style with each field name being unique). AntC ----- Original Message Follows -----
My objection is that I'm not sure if there is ever a case where "you really want things to be polymorphic over all records".
Well, I don't have a simple, really convincing example, but there are certainly things I want to play with. More importantly, DORF automatically attaches one class to each label, but this is often not what you want. For example, if you have two fields "firstname" and "lastname" the associated classes are less useful: what you really want is
class (Has r "firstname" String, Has r "lastname"
String) => HasPersonalName r
so that you can define
fullname :: HasPersonalName r => r -> String fullname r = r.firstname ++ " " ++ r.lastname
You may also want to define subclasses to express more specific conditions. In general, the compiler cannot automatically deduce what is semantically important: you need to define it yourself. The Has class is the base on which you can build.
It doesn't seem like the Haskell way to have the less safe thing as the one that's default and convenient, and to allow the programmer to layer a more-safe thing on top of it if he or she wants to. It seems more like the Haskell way to have the safer thing be the default and to require extra work if you want to do something less safe*.
I think you are using the word "safe" in a slightly misleading way. None of this is mathematically unsafe, because projections are natural (truly polymorphic). The "safety" that is broken here is nothing to do with the semantics of the language, it is to do with the semantics of the system being implemented, and that is something the compiler cannot infer. As my example above shows, it doesn't always correspond one to one with the labels.
The Haskel way is to make things as polymorphic as is mathematically safe, even when this goes beyond the programmers original intention. You can then restrict this polymorphism by giving explicit less general types in the same way as in my examples. I think my approach is more Haskel like.
Another important Haskel design consideration is to reuse parts of the language where possible, rather than introduce new structures. Type classes were originally introduced to deal with equality and numeric functions, but were reused for many things including monads. My approach achieves the same as DORF (and more), but using existing language features instead of introducing new ones.
Barney.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Please remember SPJ's request on the Records wiki to stick to the namespace issue. We're trying to make something better that H98's name clash. We are not trying to build some ideal polymorphic record system.
I must admit that this attitude really gets my hackles up. You are effectively saying that, so long as the one narrow problem you have come across is solved, it doesn't matter how bad the design is in other ways. This is the attitude that gave us the H98 records system with all its problems, and the opposite of the attitude which gave us type classes and all the valuable work that has flowed from them. Haskel is supposed to be a theoretically sound, cleanly designed language, and if we lose sight of this we might as well use C++. Whatever new records system gets chosen for Haskel, we are almost certain to be stuck with it for a long time, so it is important to get it right. Barney.
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
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.karczmarczuk@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
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 <greg@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.karczmarczuk@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
Oliver Batchelor <saulzar <at> gmail.com> writes:
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.
Thank you Oliver, yes you got it. And very restrained of you to say "not quite accurate". In the following I shall try to do the 'egoless programmer' thing. Seeing as DORF's control over namespacing is a considerable improvement over SORF (in my view), I'm particularly miffed to see an allegation that it can't do EXACTLY WHAT IT'S DESIGNED TO DO. And since that allegation has been repeated in several places, just so there's "no probable possible shadow of doubt, no possible doubt whatever", I've updated the wiki with an illustration: http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFie... #ImportExportandRepresentationhiding and attached a working example to the implementor's page. The example shows that within a single record decl: 0. You can import fieldLabel decls. 1. You can create fields that share Labels with imports. 2. You can create fields that don't share, even with the same Label name. (That is, the module system continues to control the namespace.) 3. You can prevent using the wrong field selector with the wrong record type, even if they have the same Label name. Points 2 and 3 are there especially for all the people who want multiple `name`s that label String fields but don't "mean" the same thing. The example shows that if you use the wrong `name` selector with the wrong record type, you get an instance failure (even if the record type has a field `name`). Just before they slip on the straightjacket for all this mumbling about what's in a name, one further point: - if there's a difference of "meaning" going on, - you can use the type system to manage your meanings, - with a newtype to screen the representation. That's what Chris Done's example is doing, and it's a good discipline to manage complex data structures. (Thank you Greg for posting it back on to the Records wiki front page). http://hackage.haskell.org/trac/ghc/wiki/Records#Problemswithusingthecurrent... ulenamespacemechanism Chris's post is what started me down the track of designing DORF, as an improvement over SORF, and to avoid the suggestions of sub-modules. AntC
Barney Hilken <b.hilken <at> ntlworld.com> writes:
Please remember SPJ's request on the Records wiki to stick to the namespace issue. We're trying to make something better that H98's name clash. We are not trying to build some ideal polymorphic record system.
I must admit that this attitude really gets my hackles up.
Barney.
So Barney, the obligation on you is clear: - pick one of the many theoretically sound clean designs for records - (or make up your own) - write it up on the wiki - show what work it would need to get there from where we are - encourage discussion on this forum One thing I can be pretty sure of: proposals not written up won't get implemented. AntC
participants (6)
-
AntC -
Anthony Clayden
-
Barney Hilken -
Greg Weber -
Jerzy Karczmarczuk -
Oliver Batchelor