First class labels

[Claus Reinke]

Hi Andrew,

> Claus, I don't get part of the motivation this proposal, but it might be
> because I don't use records.  

that would be an obstacle, as the major other application would 
probably be type-class-level programming;-) 

>What is the need for labels that are global between modules?  

that's actually a more general problem with Haskell development,
whenever you're trying to combine two independently developed
sub-projects that define their own auxiliary classes/instances/data 
for the same purpose (e.g., I've run into wanting to combine two 
libraries each of which had rolled their own variation of monad 
transformers, before those arrived in the standard libraries).

usually, you'd be trying to keep the subprojects separate from
each other, and with the notable exception of instances, Haskell's 
module system allows you to do that. however, there are cases where 
the subprojects are just doing the same thing twice (and where lots 
of explicit conversions are more confusing than useful). 

you can still define your own local data types and get module 
separation, and you *do* want the subprojects to talk about 
*different* Either types, if they are using those to instantiate Error 
Monads in different ways.

but you wouldn't want each of your packages to talk about a 
different type of integers, nor would you want to write conversion 
routines between A.String and B.String, or before using C.Bool 
in conditionals. in my experience, labels, once separated from 
records, fall into the same category, so there should be a common 
root for their declarations, just as there is a common root for Char, 
or Bool.

> Ie, if OpenGL and GUI each have their own
> pointX label, do you really want to identify them?  That seems a bit
> hazardous, so I would think the payoff needs to be big.  Can you give an
> argument for why labels should be global?  Is what TREX does already?

note that this need not compromise type-safety in any way. you could 
still declare your types, including labels, locally, and if you are willing to 
change the sources of say, OpenGL and wxWidgets, you could achieve 
the sharing effect by factoring out their common label definitions. the only 
problem is that it isn't practical to rewrite packages for composition, and
that Haskell's module system does not provide well for open components.

the only thing that would change is that developers would get a chance
to decide whether or not they want to share their label constants with
other packages they might know nothing about. if they are defining a 
2d cartesian coordinate system, they probably want to share even the
records (not to mention any auxiliary functions..).

note also, that only the labels and their types would be shared, not the
field types those labels are associated with, if those labels are use to
implement some variant of records. if, as happens to be the case, 
OpenGL uses Double coordinates, while wxWidgets uses Ints, the 
type system would still prevent us from mixing those: the values paired 
with the labels would differ in their types!

and yes, TREX labels, while not first-class, are implicitly declared.
so there are no record type declarations, either, but you can still
wrap your records into data constructors of different types if you
watn/need to distinguish between otherwise type-compatible records.

> Also, it seems to me that your proposal has two goals that could be
> separated, 1. implicit declaration of labels, and 2. identification of
> same-named labels across modules.  Does it make sense to consider each
> independently?

yes, that's true in a sense, and I tried to outline different options,
but 1/2 are really just different means that need to be combined 
to achieve the purpose (implicit declarations without sharing, ie.
implicitly-declared, module-specific labels, would be a mere 
convenience, but wouldn't solve the problem; sharing constraints 
as a separate concept would be interesting, and I mention that
when outlining option 2, but they are much too complicated for 
this simple purpose; and common imports would be useless if 
you'd had to go in there and add new explicit label declarations 
every time you wanted to use another package's labels).

>You can reply to the list if you'd like.

thanks, then I'll do so. if only to mention that I'm getting more 
off-list responses and queries. that is very encouraging, but since 
I don't have write access to the wiki, it is probably best to keep 
the discussion on the list, unless it is something of no general interest.

cheers,
claus