First class labels

[Claus Reinke]

[The reader will have noticed the absence of the words
 extensible polymorphic records in the subject line]

If the long-overdue overhaul of Haskell's record system
appears to be out of scope for Haskell' (??), I suggest to add 
some form of first-class labels to Haskell' (to be really useful, 
this depends on real type classes, not the cut-down version 
of Haskell 98).

I often find myself coding up my own records, which is fairly
quick and painless, though of course lacking the comfort of
a real records systems (see code at bottom of this message; 
one might add some syntactic sugar, or not).
 
The two main problems I have with this are 

(a) the need for so-called "extensions" (I see these features 
        merely as removing needless restrictions, and will be
        very disappointed if Haskell' does not provide for 
        them, not even optionally)

(b) the need to declare my labels. it is not so much the
        typing, but:
        - possible namespace overlaps (someone might
            want to use my labels as constructor names)
        - the need for a common import origin (someone
            has to declare all those labels, and all users 
            better agree on who that someone is)

This suggestion is concerned with (b). I propose to add
first class labels to Haskell' (every label is a constant, the 
only inhabitant of its type). I outline three options, of which 
option 1 is my personal favourite, followed by option 3:

Option 1: 
    remove the need to declare labels, make them identifiable 
    as such in use. TREX demonstrates that this is possible.

    in the past (when I was using Hugs more than GHC), I 
    have been known to abuse TREX, not for its records, 
    but for its labels. In other words, I'd use single-field 
    dummy records "(mylabel=())" as labels in constructions 
    like the one at the bottom of this message.

    pro: simple in use, labels have their own namespace,
            no conflicting imports, known to work
    con: need to give up some identifiable space in the
            language for labels

Option 2:
    add sharing imports to the module language. SML
    supports something like that, I think.

    that would allow importers to declare that the various
    imported declarations of a label are not in conflict, but
    refer to the very same type.
    
    pro: seems like a useful feature anyway
    con: more complex than needed for this proposal,
                and would be very verbose in use

Option 3:
    add a "magic" standard module Data.Label, which 
    implicitly exports all possible labels and only such.

    that would allow all importers to refer to a common
    origin for their label declarations. imports from that
    module would amount to declarations of shared label
    types: "import Data.Label(mylabel1,mylabel2)"

    pro: no syntax extension or separate label namespace,
            no problems with common imports
    con: no separate label namespace, labels still need to
                be declared, by means of import

Either 1 or 3 should be much easier to implement than
full records, and either option would be a small change,
avoiding the main problem of a full records system: that 
noone can agree on what the ultimate form should look 
like. Either option would enable a pragmatic approach
to the problem while we are waiting for the real records.

What do you think?
Claus

related:

- tweak the existing records system (none)
    http://hackage.haskell.org/trac/haskell-prime/ticket/27

- add overlapping or incoherent instances (probably no)
    http://hackage.haskell.org/trac/haskell-prime/ticket/54

- add FunctionalDependencies (probably no)
    http://hackage.haskell.org/trac/haskell-prime/ticket/36

- add multi parameter type classes (probably yes)
    http://hackage.haskell.org/trac/haskell-prime/ticket/49

----------------------------------------
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}

-- poor man's records using nested tuples and declared labels:

class Select label val rec | label rec -> val where
  sel :: rec -> label -> val

instance Select label val ((label,val),r) where
  sel ((_,val),_) label = val

instance Select label val r => Select label val (l,r) where
  sel (_,r) label = sel r label

-- some labels and examples

data A = A deriving Show
data B = B deriving Show
data C = C deriving Show
data D = D deriving Show

r1 = ((A,True),((B,'a'),((C,1),())))

r2 = ((A,False),((B,'b'),((C,2),r1)))

x1 r = (r `sel` A, r `sel` B, r `sel` C)