Keep the present Haskell record system!

Cale Gibbard cgibbard at gmail.com
Mon Mar 6 01:08:06 EST 2006


Efficient implementations are discussed in the paper. It looks simple
enough complexity-wise at compile time. I'm not 100% sure, but at a
glance, I don't see anything here which looks like it should be very
complex.

As for the actual runtime semantics, apart from using association
lists (linear selection, constant extension) or labelled vectors (log
selection, linear extension), records may be implemented as plain
unlabelled vectors (constant selection, linear extension), provided
that an additional extension predicate is used in the type system,
which can always be inferred and so may be hidden from the user
completely. Given that one would expect record selection to be very
common, this last option looks quite attractive.

Another nice aspect is that we'd get automatic labelled variant types
almost for free from the same machinery.

 - Cale

On 06/03/06, Lennart Augustsson <lennart at augustsson.net> wrote:
> Can it be implemented efficiently?
>
> Cale Gibbard wrote:
> > On 04/03/06, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
> >> On Saturday 04 March 2006 19:35, Claus Reinke wrote:
> >>> 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
> >> Yes. Daan Leijen's record system is the best of all the ones I have read
> >> about, not least because of its simplicity.
> >
> > I just looked at this, and it made me wonder why we all haven't jumped
> > on it. It looks pretty much ideal -- are there any known problems with
> > it? It has pretty much all the operations that you'd want in an
> > extensible record system, there are no lacks predicates to worry
> > about, type inference is complete and sound (and there are
> > constructive proofs available of this), and it doesn't look like it
> > should be all that difficult to implement (the paper even gives
> > suggestions as to possible efficient implementations). What are we
> > searching for?
> >
> >  - Cale
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org
> > http://haskell.org/mailman/listinfo/haskell-prime
> >
>
>


More information about the Haskell-prime mailing list