Keep the present Haskell record system!

[Claus Reinke]

>> On Wed, Mar 01, 2006 at 08:26:14AM +0000, Henrik Nilsson wrote:
>> > I'm increasingly convinced that the records should be left alone for
>> > Haskell', possibly modulo some minor tweaks to polish the system.

for the record:-) I'm not in favour of this part.
 
> But the main reason I can see for there being little use of these
> candidates, is that they are not compatible with current Haskell.
> 
> Thus, although I agree that none is ready for inclusion in
> Haskell-prime, I think we do need some mechanism for experimental
> records to be tried out in real Haskell implementations before the
> Haskell-double-prime committee starts its work.

however, if Malcolm's compromise could be made to work, that would
at least be some step forward: instead of waiting for someone else to
take the necessary steps, Haskell' would at least prepare for them,
and address the road-block of backwards-compatibility that has held
up better record systems for so long.

but that would have to go beyong tweaking the existing system, and
even separating out the definition into an extension isn't sufficient:

we can't just have a flag to switch support for old-style records on or off.
we need a transition path, preferably with an interface that may either be
implemented by old-style labelled fields, or by some alternative record
system. if that could be made to work, the switch would be between
old-style labelled fields and record system X.
 
> My suggestion is that we separate out everything from the Report to do
> with named-field records into something like a self-contained addendum.
> Whilst still an official part of the language standard, it might also be
> marked as a possibility for future removal.  This would make it clear
> what parts of the language could be changed (or re-used without conflict)
> in an alternative records system.

that would be useful, especially since the interface involves syntax and
types (so those Haskellers giving explicit declarations to their record-using
functions might have problems if a future alternative required contexts, eg,
for has and lacks predicates, etc..). 

one might think that a simple approach would be to separate 
labelled fields into user-level features (record syntax, patterns, updates,..)
and language-level desugaring (algebraic data types), and then to provide
a pre-processor for that to make the currently internal desugared version
explicit. the output of such a preprocessing could then be used even if
Haskell'' removed labelled fields alltogether. the problem with this is that
it would introduce structure-dependent code for applications that wanted
to avoid just that. so this is nothing but a worst-case fallback alternative.

an alternative approach would change the desugared version from data 
types to type classes, in the hope of preserving some advantages of
using labelled fields even without the syntactic sugar. so, ideally, old-style
programs could survive into Haskell'' in desugared, but still extensible
form. unfortunately, it seems more and more likely that Haskell' type 
classes will not be expressive enough for such an approach, even though
current Haskell type classes clearly are.

a more promising approach would be to specify the user-level features
of the current system, then to show at least two translations: one for
the current desugaring, and a second one to demonstrate at least one
implementation of those features in an alternative record system.

the point of that exercise would be to figure out which features of the 
current user-level view of labelled fields would make a later transition
difficult, and to mark them as deprecated or to remove them now. in
other words, the "reference" translation should not be to the most
powerful record system imagined so far, but to a fairly simple one,
which all "better" record systems ought to be able to mimic.

my current favourite for such a simple alternative record system
would be Daan Leijen's "Extensible records with scoped labels"
(TFP2005): http://www.cs.uu.nl/~daan/pubs.html

in my view, his scoped labels are not so much a feature but a
consequence of simplifying the type system: no need for lacks
or has predicates, but still extensible records without need for
declarations. if one accepts the potential for scoped labels,
lacks can be dropped, and has can be encoded in the type
structure.

so, as long as the translation doesn't make use of scoped labels,
limiting the user-level features of labelled fields to what can be
translated safely into this record system should ensure some 
level of future-proving (using his system as a reference would 
not expose changes in type contexts, but I hope that some 
form of partial type declarations will make it into Haskell';
then switching from labelled fields to, say, TREX, would
need to turn explicit signatures involving records into partial
ones).

cheers,
claus

ps. the Curry folks are looking into adding labelled fields,
    and seem to have decided to go for a trial implementation
    of Daan's system before making any decisions:
http://www.informatik.uni-kiel.de/~curry/listarchive/0406.html