Browse thread
Re: [Caml-list] Future of labels
-
Yaron M. Minsky
-
Jacques Garrigue
-
Judicael Courant
- Markus Mottl
- kahl@h...
- Chris Hecker
-
Judicael Courant
-
Jacques Garrigue
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2001-04-10 (22:44) |
From: | Brian Rogoff <bpr@b...> |
Subject: | Re: [Caml-list] Future of labels, and ideas for library labelling |
On Tue, 10 Apr 2001, Jacques Garrigue wrote: > To summarize recent posts by various people, there are two approaches > for a universal mode: > > * Take the label mode as a basis, and split libraries where needed to > avoid troubling non-labellers. > Labels, when present, are no longer optional. > > * Extend classic mode with commutation, and keep labels in libraries. > Labels are kept optional. > > Now let me explain what is the trouble with the second option. > To put it simply: you cannot have commutation, first class > functions, type inference, and allow discarding of labels in > unification. I know you'll hate this, but what about insisting on an explicit type for functions which use commuting labels? Could something like that be made to work? I think in other cases (yes, I will mention polymorphic recursion again:) we consider explicit typing to get what we want; would that work here? If so, could it be made to work so that if you don't use commuting labels you don't have to provide the type? Anyways, I think that because we have two modes, we probably still have two communities, with former OLabl users using commuting label mode and most others just doing what they've always done as well, and maybe trying labels just a little bit. It's difficult to see a way forward, and as much as you don't like it the classic mode seems a better chance for labels, as it is less obtrusive in some sense. -- Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr