The original goal was to come up with a simple solution. Perhaps that goal is unattainable, or at least attaining it has much higher cost than we had hoped. If that is the case we must take a step back and look at changing how things are done currently. Perhaps the approach that a record label becomes a global module function is just not feasible.
In the Frege <http://code.google.com/p/frege> (a Haskell with some differences implementation on the JVM) language every data type is at the same time a namespace. * the function that accesses field x of data type T is T.x * If a::T then a.x = T.x a * the function that updates field x of data type T is T.{x=} * the function that sets field x in a T to 42 is T.{x=42} * If a::T then a.{x=} and a.{x=42} are valid * the function that changes field x of a T by applying some function to it is T.{x <-} * T.{x?} is a function that returns true iff the argument was constructed with a data constructor that has field x. In the Opa language a Module is in fact a Record specially marked as a module. What do you think of the Frege system? On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber <g...@gregweber.info> wrote: > I am willing to help on this as much as I can. Unfortunately I don't think > you want me to lead the discussion or make decisions on this - many of > these discussions seem over my head. I will continue to study them though > and see if the sink in more. > > I do think almost all of these proposals want a dot selector, so it is a > good idea for Haskell to require the normal function (composition) dot to > have spaces around it - should this be brought to the Haskell > Prime committee? > > Greg Weber > > > On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones <simo...@microsoft.com > > wrote: > >> Are Records stalled out again? I am perfectly willing to leave the fate >> of records up to a willing and capable implementer. That seems much better >> than waiting another 5 years for perfection :)**** >> >> ** ** >> >> Yes, they are stalled again. The “simple solution” turned out to be not >> simple. I wrote it up at length in **** >> >> >> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields** >> ** >> >> There are various unsatisfactory aspects of the proposal, particularly >> concerning record update. I am not sure how to resolve them. **** >> >> ** ** >> >> There was essentially no reaction. As it’s quite a lot of work to >> implement, and no one seemed to care very much, I put it back on the back >> burner. So that’s where it stands.**** >> >> ** ** >> >> Meanwhile, AntC has put forth another proposal that I have not had time >> to look at in detail.**** >> >> >> http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021298.html >> **** >> >> ** ** >> >> *What this needs is someone (not me) to lead the discussion and try to >> make sure it makes progress*. For example, does AntC’s proposal work? >> Is it better than the one I articulated? Are any other variants worth >> considering? Is the gain from overloading record fields worth the pain or >> design and implementation? Volunteers, stand forth!**** >> >> ** ** >> >> Simon**** >> >> ** ** >> >> ** ** >> >> *From:* Greg Weber [mailto:g...@gregweber.info] >> *Sent:* 09 December 2011 19:38 >> *To:* Simon Peyton-Jones >> *Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org >> >> *Subject:* Re: Records in Haskell**** >> >> ** ** >> >> Are Records stalled out again? I am perfectly willing to leave the fate >> of records up to a willing and capable implementer. That seems much better >> than waiting another 5 years for perfection :)**** >> >> ** ** >> >> As an intermediate step, is it possible to put a warning in 7.4 when the >> dot operator is used without a space so that it can be reserved for usage >> with a records solution? Or will the new records solution be turned on by >> an extension anyways?**** >> >> ** ** >> >> On Mon, Nov 7, 2011 at 10:21 AM, Simon Peyton-Jones < >> simo...@microsoft.com> wrote:**** >> >> | would inclusion of such a record system into GHC mean that plans for >> | first-class labels (<http://tinyurl.com/7fppj32>) are abandoned? That >> | would be a pity, since first-class labels are very useful to implement >> | record systems that go beyond what the abovementioned record system >> | provides. See, for example, my work on records: >> | < >> http://www.informatik.tu-cottbus.de/~jeltsch/research/ppdp-2010-paper.pdf >> > >> | <http://hackage.haskell.org/package/records>**** >> >> The story is summarised at >> http://hackage.haskell.org/trac/ghc/wiki/Records >> >> First-class labels are one point in the vast swamp of competing and >> overlapping proposals for records. I think they are summarise here: >> http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords >> I am unsure which of this list of proposals you are referring to. The URL >> you quote is this >> >> http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels >> but it doesn't seem to actually contain a design, merely some options for >> a design that is implicit. If you do have a design you advocate, it would >> be good to add it to the list at >> http://hackage.haskell.org/trac/ghc/wiki/ExtensibleRecords >> perhaps explaining which of the other members of the list it subsumes. >> >> Because there are so many proposals I have not gone ahead with any of >> them. The most recent thread, articulated at >> http://hackage.haskell.org/trac/ghc/wiki/Records >> is to ask what is the *smallest change* that would solve the *most >> pressing problem*, namely the inability to use the same field name in >> different records. First class labels is (I assume) much more ambitious. >> But maybe not. >> >> Anything you can do to bring clarity to the swamp, by editing the above >> two pages, would be a great service to the community. At the moment, we >> are stuck in an infinite loop. >> >> Simon**** >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users**** >> >> ** ** >> > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users