New subject: Records in Haskell

26 Feb 2012

      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

Re: Records in Haskell

Anthony Clayden

Barney Hilken

Jerzy Karczmarczuk

Greg Weber

Oliver Batchelor

AntC

AntC

tags

participants (6)