[Haskell] Re: Re: RE: Extensible records: Static duck typing

[Ben Franksen]

Ben Franksen wrote:
> Barney Hilken wrote:
>>> From: Ben Franksen <ben.franksen at online.de>
>>> Date: 18 February 2008 21:32:29 GMT
>>> To: haskell at haskell.org
>>> Could you be more specific? Which proposals exactly do you mean and
>>> where
>>> can I read more about them?
>> 
>> Hlist is one of the ones | was thinking of. Two more are "poor man's
>> records" a.k.a. Data.Record.hs, whose author certainly believes it
>> should be the basis for the new system, and my own system,
>> downloadable from http://homepage.ntlworld.com/b.hilken/files/Records.hs
>> 
>> There is a discussion of the various possibilities on the wiki
>> http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords
>> which you are encouraged to contribute to!
> 
> Thanks, exactly the kind of pointer I had hoped for! I'll read up on the
> existing proposals.

My proposal how to proceed is to /eliminate/ candidates by the following
criteria:

(a) efficient field access
(b) requires no or only minimal /additional/ extensions to compiler or
language
(c) light-weight syntax and semantics, at least for the simple
non-polymorphic cases

My rationale for these criteria goes like this: efficient access is
necessary if we want to compete with the much simpler record systems in
mainstream languages. If records are not as light-weight (syntactically as
well as wrt run-time performance) as 'normal' Haskell data types, then
people will be reluctant to use them, especially in library APIs. Finally,
having to wait for highly experimental additional extensions to be
available, tried, and tested, would only help to indefinitely post-pone the
introduction of a usable record system.

Now, these three criteria together immediately eliminate all the 'mostly
library' proposals, including HeterogeneousCollections, Data.Record.hs, and
TypeFamilies, since in all of them records are represented as nested pairs
(more or less) and efficient field access relies on not yet available
compiler optimizations i.e. 'partial evaluation of type class programs'.
They also directly depend on advanced type system extensions that are
either only partially implemented yet (type families, type sharing), or
controversial (fundeps). Criterion (c) also eliminates proposals in which
labels must be pre-declared; it is not completely clear to me which of
the 'mostly library' proposals require how much compiler support to
completely automate this.

TREX seems to be generally agreed to be too complicated to implement and
explain.

What remains are Daan's ScopedLabels approach and SPJ's proposal which I
mentioned earlier. Both are simple to explain, support light-weight syntax,
and require only minimal or no additional (type system or other) extensions
beyond what the proposal itself specifies. These are IMO the only really
practical proposals. It is, however, unclear to me whether the ScopedLabels
proposal can be implemented effciently (AFAIR, the issue is only briefly
mentioned at the end of the paper).

Just my 2 cents.

Cheers
Ben