what about moving the record system to an addendum?

[Iavor Diatchki]

Hello,
I do not think that we should remove the current record/named fields
syntax, at least for the moment.  I use it a lot, and I do not want to
add extra pragmas or "extensions" to my cabal file.  In fact, one of
the purposes of Haskell', the way I understand it, is exactly to just
choose a stable set of extensions and give a name to them (so
decrease, not increase the number of pragmas).  I think that a new
reocrd/label system is way beyond the scope of Haskell'.  If people
want to experiment with new record systems they may already do so, by
defining a new extension.  A case in point is the Trex record system,
which is implemented in Hugs.
-Iavor

2009/7/7 Ravi Nanavati <ravi at bluespec.com>:
> 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
> NamedFields/TraditionalRecordSyntax/WhateverWeEndUpCallingIt
> 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
> definition).
> 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?
>
> Thanks,
>
>  - Ravi
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>