Re: what about moving the record system to an addendum?

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 :

2009/7/7 Duncan Coutts :

...

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime