First class labels

[Claus Reinke]

| the concrete proposal is to address one of these remaining issues,
| namely how to identify record field labels as such. for that, I
| outlined three options, although that outline perhaps wasn't concrete 
| enough:
| 
| 1. make label declarations unneccessary (eg., #pointX :: #PointX)

effect on the type system: a new (meta-)rule for a new kind of 
literal constants: whenever we see something looking like 
" '#'<identifier> ", its type is " '#'<Identifier>".

Essentially the same as for other literals: whenever we see
something looking like " [0-9]+ ", its type is " Num a => a ". 
whenever we see " True ", its type is " Bool ", etc. .

Similar to numeric literals, there'd be no place in source where
all those literals/labels are declared, but literals of the same type 
in different modules would be compatible. So this would work
without problems:

    module A
    main = #pointX

    module B
    main = #pointX

    module C
    import A
    import B
    main = print [A.main,B.main]

| 2. make type sharing expressible (something like the sharing
|     constraints in Standard ML's module language, to allow you to
|     say when two declarations from different imports refer to the
|     same type)

this is definitely a type system issue. if we have

    module A where 
    data PointX = PointX deriving Show
    main = print PointX

    module B where 
    data PointX = PointX deriving Show
    main = print PointX

    module C -- this doesn't work!
    import A
    import B
    main = print PointX -- conflict here! ambiguous occurrence..

we have a problem. in a simple form, the sharing constraints I 
had in mind would permit us to express which structurally equivalent 
declarations define *the same type*. that is, module C would be

    module C
    import A
    import B
    sharing A.PointX B.PointX
    main = print PointX 
                -- no conflict, A.PointX and B.PointX have been 
                -- identified, refer to the same type

the type system would need to unify the shared types. to make 
that safe, it would need to check for structural equivalence of the
declarations when encountering a sharing constraint; if successful, 
both shared types would afterwards be seen as synonyms for 
one and the same type.

A very minimal version of this option would suffice for labels;

in general, this kind of sharing constraints is non-trivial, but useful
(if we could share classes and instances defined multiple times,
like the instances for (,,,,,,,,,,,) discussed in other threads).

| 3. introduce a least upper bound for shared label imports
|     (so A and B could just 'import Data.Label(pointX)', which
|      would magically provide the shared declaration for pointX)

with this option, the modules would look like this

    module A
    import Data.Label(pointX)

    module B
    import Data.Label(pointX)
    
    module C
    import A
    import B
    main = print pointX 
                -- no conflict, A.pointX and B.pointX are the same

this would have a similarly small effect on the type system as option 1,
only that instead of syntax, we'd use imports from the reserved module
'Data.Label' to identify what is a label and what is not.

whenever encountering an ' import Data.Label(<identifier>) ', we
interpret ' Data.Label.<identifier> ' as a constant of type 
' Data.Label.<Identifier> ' and ' <identifier> ' as a constant of
type ' <Identifier> '. the difference to normal imports is that the
compiler/type system needs to know about 'Data.Label'.

In other words, 'Data.Label' does not exist in source or object code,
but as a hint for the compiler/type system. Any identifier imported from
there is a label of its own type, nothing else can be imported from there.

sorry for being so difficult to understand. the questions help.

cheers,
claus