Records in Haskell

Gábor Lehel illissius at gmail.com
Sun Jan 8 07:03:16 CET 2012 

2012/1/8 Gábor Lehel <illissius at gmail.com>:
> Another thing that would be nice is lenses to solve the
> nested-record-update problem - at least the room to add them later.
> Most of the proposed syntax would be unaffected, but you'd need some
> syntax for the lens itself... I'm not sure what it might be. Would it
> be terrible to have T.x refer to a lens rather than a getter? (I don't
> know how you'd refer to the getter then, so probably yeah.) Or maybe {
> T.x }, building backwards from { T.x = }?

Oh, never mind this part, wasn't thinking straight. D'oh.


>
>
> On Sun, Jan 8, 2012 at 2:40 AM, Greg Weber <greg at gregweber.info> wrote:
>> I have updated the wiki - the entry level page [1] compares the different
>> proposals and points to a more fleshed out explanation of the Frege proposal
>> [2].
>>
>> I think I now understand the differences between the existing proposals and
>> am able to provide leadership to move this forward. Let me summarize the
>> state of things:
>> There is a debate over extensible records that we are putting off into the
>> future. Instead we have 2 proposals to make things better right now:
>> * an overloaded record fields proposal that still has implementation
>> concerns
>> * a name-spacing & simple type resolution proposal that is awaiting your
>> critique
>>
>> The Frege language originally had overloaded record fields but then moved to
>> the latter system. The existing experience of the Frege language is very
>> fortunate for us as we now have some experience to help inform our own
>> decision.
>>
>> Greg Weber
>>
>> [1] http://hackage.haskell.org/trac/ghc/wiki/Records
>> [2] http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
>>
>>
>> On Wed, Jan 4, 2012 at 7:54 AM, Greg Weber <greg at gregweber.info> wrote:
>>>
>>> The Frege author does not have a ghc mail list account but gave a more
>>> detailed explanation of how he goes about TDNR for records and how often it
>>> type checks without annotation in practice.
>>>
>>> A more general explanation is here:
>>>
>>> http://www.reddit.com/r/haskell/comments/nph9l/records_stalled_again_leadership_needed/c3di9sw
>>>
>>> He sent a specific response to Simon's mail list message, quoted below:
>>>
>>> Simon Peyton-Jones is absolutely correct when he notes:
>>>
>>> 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?
>>>
>>> The way it is done in Frege is such that, if you have a function that uses
>>> or updates (nondestructively, of course) a "record" then at least the type
>>> constructor of that record has to be known. This is no different than doing
>>> it explicitly with case constructs, etc., just here you learn the types from
>>> the constructors you write in the patterns.
>>>
>>> Hence, it is not so that one can write a function that updates field f to
>>> 42 for any record that contains a field f:
>>>
>>> foo x = x.{f=42}    -- type annotation required for foo or x
>>>
>>> In practice this means you'll have to write a type annotation here and
>>> there.
>>> Often, the field access is not the only one that happens to some variable
>>> of record type, or the record is the result of another function application.
>>> In such cases, the type is known.
>>> I estimate that in 2/3 of all cases one does not need to write (T.e x) in
>>> sparsely type annotated code, despite the fact that the frege type checker
>>> has a left to right bias and does not yet attempt to find the type of x in
>>> the code that "follows" the x.e construct (after let unrolling etc.)
>>> I think one could do better and guarantee that, if the type of x is
>>> inferrable at all, then so will be x.e (Still, it must be more than just a
>>> type variable.)
>>>
>>> On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber <greg at gregweber.info> wrote:
>>>>
>>>>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> Work is punishment for failing to procrastinate effectively.



-- 
Work is punishment for failing to procrastinate effectively.

More information about the Glasgow-haskell-users mailing list