[Haskell-cafe] Return of the revenge of the revisit of the extensible records, reiterated

[AntC]

> Atze van der Ploeg <atzeus <at> gmail.com> writes:
> 
> (see 
http://www.haskell.org/haskellwiki/CTRex#Duplicate_labels.2C_and_lacks).
> I think duplicate labels are nice in some situations and bad in other 
situations. 
> 

Thank you Atze for a well-written description. 

I think there might be a couple of typos there?

    (c, r'') = decomp r x      -- rhs s/b: decomp r' x ??

    extendUnique :: (..., l :\r ) => ...
                  -- s/b: r :\ l  ??

Your "motivation" example is hard to follow without knowing what `decomp` 
does. (IOW, it is not showing me a motivation ;-)

I'm puzzled by this in the implementation notes 4.2 Records:
"Here we see that a record is actually just a map from string to the 
sequence of values. Notice that it is a sequence of values and not a 
single value, because the record may contain duplicate labels." 

It sounds like there's an overhead in being able to support duplicate 
labels (even if I don't want duplicates in my records)?
Is there a performance penalty at run-time with extending/prepending and 
restricting/pretruncating, to keep the invariant re the i-th value?

Leijen allowed duplicate labels to make a virtue of necessity IMO. There 
has not been an extensible records proposal before or since for duplicate 
labels. (TRex certainly didn't do it.) His 'necessity' was ease of 
implementation.
This sequence of values stuff seems to make a more difficult 
implementation for the sake of providing a 'feature' that nobody's asked 
for(?)


There's one 'advanced feature' of extensible records that I'd be 
interested in: merging records by label, as is done for 'Natural Join'.

    a row with labels {x, y, z} merge labels {y, z, w}
    returns a Maybe row with {x, y, z, w}
    providing the types paired with y and z are the same
    and the values are the same
    (otherwise return Nothing)

It's absolutely essential _not_ to duplicate labels in this case.

AntC