Records in Haskell

[Greg Weber]

On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones
<simonpj at 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 <simonpj at 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
>
> ****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120101/d3f96756/attachment-0001.htm>