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
