Overloaded record fields

[Dominique Devriese]

Simon,

I see your point.  Essentially, the original proposal keeps the
namespace for field names syntactically distinguishable from that of
functions, so that the type given to "r.foo" doesn't depend on what is
in scope.  (.foo) is always defined and it is always a function of
type "(r { foo::t }) => r -> t". With the "orthogonal proposal", it
would only be defined if there is a record with a foo field in scope,
although its definition or type does not actually depend on the
record.   One would then need to define an Unused record with a field
foo, or declare the following
  foo :: r { foo ::t} => r -> t
  foo = getFld
to essentially declare that foo should be treated as a field selector
and I'm not even sure if type inference would work for this
definition... Maybe we could provide syntax like a declaration "field
foo;" as equivalent to the latter, but I have to acknowledge that this
is a downside for the "orthogonal proposal".

Regards,
Dominique

2013/6/28 Simon Peyton-Jones <simonpj at microsoft.com>:
> | Folks, I'm keenly aware that GSoC has a limited timespan; and that there
> | has already been much heat generated on the records debate.
>
> I am also keenly aware of this.  I think the plan Ant outlines below makes sense; I'll work on it with Adam.
>
> I have, however, realised why I liked the dot idea.  Consider
>
>         f r b = r.foo && b
>
> With dot-notation baked in (non-orthogonally), f would get the type
>
>         f :: (r { foo::Bool }) => r -> Bool -> Bool
>
> With the orthogonal proposal, f is equivalent to
>         f r b = foo r && b
>
> Now it depends.
>
> * If there is at least one record in scope with a field "foo"
>   and no other foo's, then you get the above type
>
> * If there are no records in scope with field "foo"
>   and no other foo's, the program is rejected
>
> * If there are no records in scope with field "foo"
>   but there is a function "foo", then the usual thing happens.
>
> This raises the funny possibility that you might have to define a local type
>         data Unused = U { foo :: Int }
> simply so that there *is* at least on "foo" field in scope.
>
> I wanted to jot this point down, but I think it's a lesser evil than falling into the dot-notation swamp.  After all, it must be vanishingly rare to write a function manipulating "foo" fields when there are no such records around. It's just a point to note (NB Adam: design document).
>
> Simon
>
> | -----Original Message-----
> | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-
> | users-bounces at haskell.org] On Behalf Of AntC
> | Sent: 27 June 2013 13:37
> | To: glasgow-haskell-users at haskell.org
> | Subject: Re: Overloaded record fields
> |
> | >
> | > ... the orthogonality is also an important benefit.
> | >  It could allow people like Edward and others who dislike ...
> | >  to still use ...
> | >
> |
> | Folks, I'm keenly aware that GSoC has a limited timespan; and that there
> | has already been much heat generated on the records debate.
> |
> | Perhaps we could concentrate on giving Adam a 'plan of attack', and help
> | resolving any difficulties he runs into. I suggest:
> |
> | 1. We postpone trying to use postfix dot:
> |    It's controversial.
> |    The syntax looks weird whichever way you cut it.
> |    It's sugar, whereas we'd rather get going on functionality.
> |    (This does mean I'm suggesting 'parking' Adam's/Simon's syntax, too.)
> |
> | 2. Implement class Has with method getFld, as per Plan.
> |
> | 3. Implement the Record field constraints new syntax, per Plan.
> |
> | 4. Implicitly generate Has instances for record decls, per Plan.
> |    Including generating for imported records,
> |    even if they weren't declared with the extension.
> |    (Option (2) on-the-fly.)
> |
> | 5. Implement Record update, per Plan.
> |
> | 6. Support an extension to suppress generating field selector functions.
> |    This frees the namespace.
> |    (This is -XNoMonoRecordFields in the Plan,
> |     but Simon M said he didn't like the 'Mono' in that name.)
> |    Then lenses could do stuff (via TH?) with the name.
> |
> |    [Those who've followed so far, will notice that
> |     I've not yet offered a way to select fields.
> |     Except with explicit getFld method.
> |     So this 'extension' is actually 'do nothing'.]
> |
> | 7. Implement -XPolyRecordFields, not quite per Plan.
> |    This generates a poly-record field selector function:
> |
> |        x :: r {x :: t} => r -> t    -- Has r "x" t => ...
> |        x = getFld
> |
> |     And means that H98 syntax still works:
> |
> |        x e     -- we must know e's type to pick which instance
> |
> |     But note that it must generate only one definition
> |     for the whole module, even if x is declared in multiple data types.
> |     (Or in both a declared and an imported.)
> |
> |     But not per the Plan:
> |     Do _not_ export the generated field selector functions.
> |     (If an importing module wants field selectors,
> |      it must set the extension, and generate them for imported data
> | types.
> |      Otherwise we risk name clash on the import.
> |      This effectively blocks H98-style modules
> |      from using the 'new' record selectors, I fear.)
> |     Or perhaps I mean that the importing module could choose
> |     whether to bring in the field selector function??
> |     Or perhaps we export/import-control the selector function
> |     separately to the record and field name???
> |
> |     Taking 6. and 7. together means that for the same record decl:
> |     * one importing module could access it as a lens
> |     * another could use field selector functions
> |
> | 8. (If GSoC hasn't expired yet!)
> |    Implement -XDotPostfixFuncApply as an orthogonal extension ;-).
> |
> | AntC
> |
> |
> |
> |
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users