Re: Records in Haskell

1 Mar 2012

      Ian Lynagh  writes:
...
On Thu, Mar 01, 2012 at 08:52:29PM +0000, AntC wrote:
...
And you get "In my opinion, this is ugly, ...
That comment was from strake888, not SPJ?
Thanks Ian, you're right. Specifically, it's 'igloo's tweak to the proposal 
and 'strake888's comment. (I had erroneously thought the whole of that page 
was SPJ's, and I hadn't much re-read it since SPJ posted it.)
...
Personally, in the context of Haskell (where the case of the first
character often determines the behaviour, e.g. a pattern of Foo vs foo),
I don't think it's too bad.
Hmm. Upper case in an expression always means data constructor (or qualified 
name). (You've possibly not been watching the outrage at changing the meaning 
of `.` ;-)

Also this would be ambiguous:

    object.SubObject.Field.subField

    -- are the `SubObject` and `Field` (private) field selectors,
    -- or a qualified name for subField?
    -- or perhaps SubObject.Field is a qualified private field selector?

Putting parentheses would cut out some of those interpretations, but not all 
of them??

In terms of scope control, I think (I'm guessing rather) you do get similar 
behaviour to DORF, with the added inconvenience of:
* an extra arg to Has (how does the constraint sugar cope?)
    r{ field :: Int } => ...
    r{ Field :: Int } => ...               -- ? does that look odd
                  -- suppose I have two private namespaces
    r{ Field :: Int ::: Field1 } => ...     -- ??
    r{ (Field ::: Field2) :: Int } => ...   -- ???
* something(?) extra in record decls:
    data PublicRecord = Pub { field :: Int }
    data PrivateRecord = Priv { Field :: Int }            -- ?
    data PrivateRecord = Priv { Field :: Int ::: Field2 } -- ??
* a need for equality constraints between Kind and Type
  (that's the ft ~ FieldT bit)
  The class decl and instances are 'punning' on tyvar `ft`
   being both a type and a Kind.
  Is that even contemplated with Kinds?
* a need for something(?) different on record update syntax:
    pubRec{ field = 27 }
    privRec{ Field = 92 }      -- does upper case there look odd to you?
    privRec{ Field = 87 ::: Field2 }

("ugly" is a mild reaction, the more I think about it.)
...
But I think you are agreeing that (leaving aside the issue of whether
the design is reasonable) the above variant would indeed allow the user
to choose the behaviour of either SORF or DORF.
No, not the "user to choose", but the implementor. We can't possibly try to 
support both approaches.

AntC