what about moving the record system to an addendum?

Ravi Nanavati ravi at bluespec.com
Tue Jul 7 10:28:11 EDT 2009

2009/7/7 Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
> On Mon, 2009-07-06 at 18:28 -0700, John Meacham wrote:
>> Well, without a replacement, it seems odd to remove it. Also, Haskell
>> currently doesn't _have_ a record syntax (I think it was always a
>> misnomer to call it that) it has 'labeled fields'. None of the proposed
>> record syntaxes fit the same niche as labeled fields so I don't see them
>> going away even if a record syntax is added to haskell in the future.
> The people proposing this can correct me if I'm wrong but my
> understanding of their motivation is not to remove record syntax or
> immediately to replace it, but to make it easier to experiment with
> replacements by making the existing labelled fields syntax a modular
> part of the language that can be turned on or off (like the FFI).
> I'm not sure that I agree that it's the best approach but it is one idea
> to try and break the current impasse. It seems currently we cannot
> experiment with new record systems because they inevitably clash with
> the current labelled fields and thus nothing changes.

I think it is a powerful approach to try and break the current impasse
for the following reasons:

1. Once implemented, Hackage and Cabal will soon give us accurate data
on what publicly available Haskell code does and does not depend on
2. Once deprecated, people will be encouraged to not depend on the
traditional record syntax where the cost of avoiding it is small (I'm
thinking of situations like the mtl-accessors / run functions where
the traditional syntax is saving something like one function
3. Champions of alternative record syntaxes will know what on Hackage
they can use out-of-the-box and what things they'd want to consider
re-writing as examples of how their approach is superior.

Does anyone have a concrete dea of what it would take to carve out the
existing syntax as an addendum?


 - Ravi

More information about the Haskell-prime mailing list