Thu, 10 Feb 2000 23:17:13 +1100 (EST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> pisze:
> Could we please have lightweight extensible records for Haskell
> (as in the paper by (Mark|Simon Peyton) Jones in the 1999 Haskell
> Workshop).
(http://www.cse.ogi.edu/~mpj/pubs/recpro.ps.gz)
I've read it. I don't understand why to separate concepts of rows
and record types, instead of having "a type which is known to be
a record type", at least on the level visible for the programmer.
So instead of
type Point r = (r | x::Int, y::Int)
type Colored r = (r | c::Color)
type ColoredPoint r = Point (Colored r)
p :: {ColoredPoint()}
-- Point, Colored, ColoredPoint :: row -> row
it would be
type Point r = {r | x::Int, y::Int}
type Colored r = {r | c::Color}
type ColoredPoint r = Point (Colored r)
p :: ColoredPoint()
-- Point, Colored, ColoredPoint :: recordType -> recordType
-- where recordType is something like a subkind of *.
There is a typo on page 6,
move :: (r\x, r\y) => Int -> Int -> Point r -> Point r
It should be
move :: (r\x, r\y) => Int -> Int -> {Point r} -> {Point r}
But it is not a typo when rows and records are more unified :-)
(Not to mention that I got used to () as a unit type...)
------------------------------------------------------------------------
A minor problem. If tuples are records, field names should be such
that alphabetic order gives the sequential order of fields, or have
a special rule of field ordering for names of tuple fields...
------------------------------------------------------------------------
In general I don't quite like the fact that records are getting more
anonymous. Magical instances of basic classes? How inelegant.
If I want the record type to have an identity, it will have to be
wrapped in a newtype, so I must think at the beginning if I will ever
want to write specialized insances for it and then all the code will
depend on the decision. Currently a datatype with named fields has
both an identity and convenient syntax of field access. (And why
newtype is not mentioned in section 5.1?)
I like name equivalence where it increases type safety. Extensible
records promote structural equivalence.
Unfortunately the proposal seems to increase the number of
irregularities and inelegant rules...
If expr.Constructor for a multiparameter constructor yields a tuple,
then for an unary constructor it should give a 1-tuple, no? I know
it would be extremely inconvenient, especially as newtypes are more
used, so I don't propose it, but it is getting less regular. What
about nullary constructors - empty tuple? :-)
I don't say that I don't like the proposal at all, or that I never
wanted to have several types with the same field names. But it is
not clean for me, it's a compromise between usability and elegance,
and from the elegance point of view I like current records more.
Maybe it would be helpful to show how to translate a program with
extensible records to a program without them (I guess it's possible
in a quite natural way, but requires global transformation of the
whole program).
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a22 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
