On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones <simo...@microsoft.com>wrote:
> Frege has a detailed explanation of the semantics of its record > implementation, and the language is *very* similar to Haskell. Lets just > start by using Frege's document as the proposal. We can start a new wiki > page as discussions are needed.**** > > ** ** > > If it’s a serious proposal, it needs a page to specify the design. > Currently all we have is a paragraph on > http://hackage.haskell.org/trac/ghc/wiki/Records, under “Better name > spacing”.**** > > ** ** > > As previously stated on this thread, the Frege user manual is available > here:**** > > http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf**** > > see Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type > Declaration - Constructors with labeled fields)**** > > ** ** > > To all those concerned about Records: look at the Frege implementation and > poke holes in it. **** > > ** ** > > Well the most obvious issue is this. 3.2 says **** > > *e*.*m *= (*T*.*m e*) if the expression *e *has type *t *and the type > constructor**** > > of *t *is *T *and there exists a function *T*.*m* > > But that innocent-looking statement begs the **entire** question! How do > we know if “e has type t? This is the route ML takes for arithmetic > operators: + means integer plus if the argument is of type Int, float plus > if the argument is of type Float, and so on. > **** > > ** ** > > Haskell type classes were specifically designed to address this situation. > And if you apply type classes to the record situation, I think you end up > with**** > > http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields > More specifically I think of this as TDNR, which instead of the focus of the wiki page of maintaining backwards compatibility and de-surgaring to polymorphic constraints. I had hoped that there were different ideas or at least more flexibility possible for the TDNR implementation. > **** > > ** ** > > Well, so maybe we can give up on that. Imagine Frege without the above > abbreviation. The basic idea is that field names are rendered unique by > pre-pending the module name. As I understand it, to record selection one > would then be forced to write (T.m e), to select the ‘m’ field. That is > the, qualification with T is compulsory. The trouble with this is that > it’s **already** possible; simply define suitably named fields**** > > data T = MkE { t_m :: Int, t_n :: Bool }**** > > Here I have prefixed with a (lower case version of) the type name. So we > don’t seem to be much further ahead.**** > > ** ** > > Maybe one could make it optional if there is no ambiguity, much like > Haskell’s existing qualified names. But there is considerable ambiguity > about whether T.m means **** > > m imported from module T**** > > or**** > > the m record selector of data type T > If there is ambiguity, we expect the T to be a module. So you would need to refer to Record T's module: OtherModule.T.n or T.T.n Alternatively these conflicts could be compilation errors. Either way programmers are expected to structure their programs to avoid conflicting names, no different then they do now. **** > > ** ** > > Perhaps one could make it work out. But before we can talk about it we > need to see a design. Which takes us back to the question of leadership.** > ** > > > I am trying to provide as much leadership on this issue as I am capable of. Your critique is very useful in that effort. At this point the Frege proposal without TDNR seems to be a small step forward. We can now define records with clashing fields in the same module. However, without TDNR we don't have convenient access to those fields. I am contacting the Frege author to see if we can get any more insights on implementation details. > Simon**** > > ** ** > > ** ** > > We only want critiques about**** > > * achieving name-spacing right now**** > > * implementing it in such a way that extensible records could be > implemented in its place in the future, although we will not allow that > discussion to hold up a records implementation now, just possibly modify > things slightly.**** > > ** ** > > Greg Weber**** > > ** ** > > On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones <simo...@microsoft.com> > wrote:**** > > | The lack of response, I believe, is just a lack of anyone who > | can cut through all the noise and come up with some > | practical way to move forward in one of the many possible > | directions.**** > > You're right. But it is very telling that the vast majority of responses > on > > http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/ > were not about the subject (leadership) but rather on suggesting yet more, > incompletely-specified solutions to the original problem. My modest > attempt to build a consensus by articulating the simplest solution I could > think of, manifestly failed. > > The trouble is that I just don't have the bandwidth (or, if I'm honest, > the motivation) to drive this through to a conclusion. And if no one else > does either, perhaps it isn't *that* important to anyone. That said, it > clearly is *somewhat* important to a lot of people, so doing nothing isn't > very satisfactory either. > > Usually I feel I know how to move forward, but here I don't. > > Simon > > **** > > ** ** >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
