> After looking up the topic some more, I could still find nothing
> "broken" about the records in haskell98.
they are not really "broken", but they are not really "records", either.
they are a collection of conventions for using labelled fields in algebraic
data types. as such, if they are not difficult to implement, that was all
the goal. and if they have various serious limitations in use, that was
all as expected (need for declarations, labels in global name space,
can't be reused in multiple records, no record extension, ...., the list
is long).
> There are, however, some wishes for extensions and improvements.
> But as soon as such wishes cease, the language is dead...
what was not expected was that now there are lots of programs using
these pseudo-records, so further experimentation to get beyond this
gap-filling interim solution has ground to a halt so as to avoid breaking
existing code.. by fixing on this interim solution, there's a dead branch
in the otherwise very lively haskell tree..
> What's more, even the ghc does not support anything more than the
> haskell98 version of records.
hugs does support TREX (and has done so for years),
http://cvs.haskell.org/Hugs/pages/hugsman/exts.html#sect7.2
which transcend many of the problems of haskell records (no declarations
needed, field reuse, record extension, ..), but couldn't steal syntax from
haskell records, and don't support record concatenation well (you can
use the old record-concatenation-for-free trick, but then you run into
issues when you need to combine that with type class programming).
ghc does support so many other extensions that, apart from the
problem of needing to support Haskell 98 users, there is the question
of feature interaction. as long as implementation effort is non-trivial,
the limited developer resources are not going to be invested on new
records unless there is a good chance that those new records will be
the last records for some time to come!-)
you can implement your own extensible records in ghc Haskell, see,
eg., the code (Data.Record.hs) attached to ticket #92 in the Haskell
prime discussion:
http://hackage.haskell.org/trac/haskell-prime/ticket/92
does Curry have type classes? if not, that is no option, but you might
want to look into Daan Leijen's TFP 2005 paper "Extensible records
with scoped labels"
http://www.cs.uu.nl/~daan/pubs.html
he drops the "lacks" predicate, which most extensible record systems
use to encode absence of record fields. that has the odd effect of
allowing multiple occurrences of a field label in the same record, but
is still type-safe, and the real bonus of this is that the types and the
type system modifications become drastically simpler (no need for
"lacks" predicates, and the "has" predicates can be encoded in the
type structure). so that looks promising.
> In addition the haskell98 version is quite easy to implement
> whereas approaches like the one in the paper above are
> considerably more demanding to realize. Thus, I propose to
> take the haskell98 version of records with labeld fields for Curry.
they are not all bad, and have served haskell users as a workaround
for some time. but, whatever you do, try to prepare for future change
better than haskell did. you could try to desugar uses of records into
plain curry, so that people could play with alternative desugarings, or
keep their desugared code intact when a new record system comes
around..
the problem with that is that Curry is probably not expressive enough
to encode a typed extensible record system without extending the
type system, and desugaring into position-dependent constructor
accesses is not really helpful as that is exactly the bit you want to
avoid when using records.. which is where the Haskell records
discussion seems stuck at the moment (at least in this person's
opinion;).
cheers,
claus
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Feb 27 2006 - 13:37:36 CET