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 <r...@bluespec.com>: > 2009/7/7 Duncan Coutts <duncan.cou...@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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime