RE: [Caml-list] Future of labels

RE: [Caml-list] Future of labels

[Manuel Fahndrich]

I use label in classic mode, mostly to disambiguate arguments of the
same type and a little bit for documentation.

To see if I could do with modern mode, I tried to compile my current
code base with -modern. This seems to not be too bad, except for 2
things, one being a show stopper:

1) The standard library requires ~f: labels on many function arguments.
That seems silly. I basically had to add ~f: to many places where it did
not add disambiguation (f is not a very explicit name). I can see that
for partial applications that might be useful, but still I found this a
bit annoying.

2) If some library function requires a function argument with labeled
arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
and I happen to have a function around that would do the right fold
operation, except that it is unlabeled or has different labels, then I'm
stuck. I have to write an eta conversion. Why isn't an explicit cast to
change the labels of a function sound? I tried that and it didn't work.

Other than the above, it seems that a casual user like me could move
from classic to modern, especially if there are some further benefits
like partial applications in different orders.  One thing that needs
improvement though are the error messages. Because the compiler tries to
reorder arguments etc., forgetting a label spits out really whacky
messages like, this function expects too many arguments.

-Maf
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Jacques Garrigue]

Nice, it seems that we can have a relaxed discussion this time :-)

OK, I'll first try to  correct some (potential) misunderstandings.

* I'm not sure this is a misunderstanding, but at least it may seem
  that some (Chris, Arturo) are implying that optionals argument do
  not commute in classic mode. They do commute in both classic and
  label mode, and there is no plan to change this behavior. That
  means that if you are only interested in labels on optional
  arguments, classic mode is already enough.

* The possibility to "omit labels" in classic mode, and to "omit
  optional arguments" in both modes may be confusing. These are
  completely unrelated features: the worst wording would be to say
  "labels on non-optional arguments are optional in classic mode"

* The rules in the P.S. of my previous mail describe a potential new
  version for _classic_ mode. This does not replace label mode.

* From both theory and implementation point of view, classic mode is
  not simpler than label mode. They both share optional arguments,
  which is the most complex part.

Otherwise it seems that we've got a nice array of answers, covering
everything from the die-hard non-labelist (Chris) to the die-hard
labelist (myself).
Sorry for Judicael, but I see no way to satisfy everybody with a single
mode. (You don't expect me to just drop the label mode, and be happy
with classic, no ?)

Yet, I see no strong support for the label features of classic mode:
* decorative labels in interfaces
  (I thought it could be very useful, particularly if one uses
   ocamlbrowser.)
* the ability to write labels in the code, just to increase safety

On the other hand Manuel expresses an opinion I've heard a few times:
moving to label mode might be nice, if the price to pay was not so
high.

To keep the discussion open, here is a 3rd alternative, which involves
making label mode the default mode, removing labels from the standard
library (to keep compatibility with ocaml 2, that's paramount), and
keeping a simplified classic mode for those who don't want to hear of
labels at all. 

* Label mode as default, with no labels in the standard library
  This makes moving to label mode very easy, the only needed
  modifications are when using new libraries that have labels.
  For current label mode users, some (partial) compatibility libraries
  would be provided, so that they (I?) don't have to drop all their
  dear(?) labels.
  (I'm mostly concerned with Pervasives, List, Array, String, and Unix)

* The simplified classic mode would simply prohibit writing labels on
  non-optional arguments in function application. You're free to write
  them anywhere else (abstraction or interfaces), but they are simply
  ignored, and never cause a type error.
  Basically that means that the only rule for non-optional parameters is
        (fun ~l:x -> e) v --> e[v/x]
  That makes all the theory simpler, and we recover soundess :-)
  Only problem: it is no longer possible to write everything in the
  intersection of classic and label mode. I generally try to do this
  when I write examples, but this would become impossible with some
  libraries.
  As a result this mode would have to be demoted: documentation is
  written for default mode, and no-label mode users are on their own
  to remove spurious labels.
  Even demoted, label users might still need it for some
  administrative tasks, like adding a labeled interface to a
  non-labeled library.

Would Chris (who doesn't write the labels anyway) be happy with
something like that ?
Would others enjoy moving to label mode at no cost (with libraries
compatible with 2.x) ?
That is, would they be ready to write more labels when they use
labeled libraries (like labltk) ?
Are there some real users of classic mode around (who use what I
called its "label features"), and would they fit in any of these two
categories ?
How much do label users care for having labels in the standard library?

Here are a few more answers to Manuel, whose post was closest to this
proposal:

From: "Manuel Fahndrich" <maf@microsoft.com>

> I use label in classic mode, mostly to disambiguate arguments of the
> same type and a little bit for documentation.

Nice, a real classic mode user!

> To see if I could do with modern mode, I tried to compile my current
> code base with -modern. This seems to not be too bad, except for 2
> things, one being a show stopper:
> 
> 1) The standard library requires ~f: labels on many function arguments.
> That seems silly. I basically had to add ~f: to many places where it did
> not add disambiguation (f is not a very explicit name). I can see that
> for partial applications that might be useful, but still I found this a
> bit annoying.

Not really for partial application (you rarely want to apply to a list
before the function), but rather for layout. Mostly a question of
taste, but if you like it really changes the way you use functionals.

Anyway, if we remove labels from the standard library, this would
solve the problem.
 
> 2) If some library function requires a function argument with labeled
> arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b)
> and I happen to have a function around that would do the right fold
> operation, except that it is unlabeled or has different labels, then I'm
> stuck. I have to write an eta conversion. Why isn't an explicit cast to
> change the labels of a function sound? I tried that and it didn't work.

The notion of soundness being with respect with an untyped reduction
semantics (cf http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/),
changing labels through a cast cannot be sound...

Is it that big a problem in practice ?
I really doubt it: I discussed it with some heavy Haskell users, and
repeatedly got the answer that they don't use fold because this
produces unreadable code. Labels and eta-expansion are just necessary
steps to make it readable.

Anyway, if we remove....
 
> Other than the above, it seems that a casual user like me could move
> from classic to modern, especially if there are some further benefits
> like partial applications in different orders.  One thing that needs
> improvement though are the error messages. Because the compiler tries to
> reorder arguments etc., forgetting a label spits out really whacky
> messages like, this function expects too many arguments.

So, you are rather a frustrated potential label mode user than a happy
classic mode user ?

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Markus Mottl]

On Fri, 30 Mar 2001, Jacques Garrigue wrote:
> Would others enjoy moving to label mode at no cost (with libraries
> compatible with 2.x) ?

It might be worth trying as long as there remains a "way back". I could
have tried it earlier, of course, but as is probably true for others,
big steps (and it is a big one) are not easily taken unless somebody
pushes you...

> How much do label users care for having labels in the standard library?

If label mode really becomes the default mode, I wouldn't mind some mild
labelling in the standard library. Let's just don't become too hard-core
right from the start...

> Not really for partial application (you rarely want to apply to a list
> before the function), but rather for layout. Mostly a question of
> taste, but if you like it really changes the way you use functionals.

Being able to write the code of a functional at the end of some function
application is surely an advantage when using commuting labels.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[kahl]

Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> replied to
  "Manuel Fahndrich" <maf@microsoft.com>:

> > 1) The standard library requires ~f: labels on many function arguments.
> > That seems silly. I basically had to add ~f: to many places where it did
> > not add disambiguation (f is not a very explicit name). I can see that
> > for partial applications that might be useful, but still I found this a
> > bit annoying.
> 
> Not really for partial application (you rarely want to apply to a list
> before the function), but rather for layout. Mostly a question of
> taste, but if you like it really changes the way you use functionals.
> 
> Anyway, if we remove labels from the standard library, this would
> solve the problem.

I am a long-time label user (having started when OCaml still was
Caml Special Light) and I have therefore gone through quite a few
relabellings of the standard library.
They never really hurt me (with a 50 module 30000 line project) ---
only when labels went away, it meant trouble.
(To make it clear: I ONLY use label mode and do not intend to switch.)

Jacques' words seem to indicate that there seems to be a
complete unlabelling of the standard library in the works ---
I must confess that I do not like that at all.
(Is my interpretation right? I got the impression that
 this was the only change intended for label mode.)
Especially for the ``f'' label!
(This was ``fun'' before the OCaml/OLabl merger
 and had to be changed to accommodate the new rule that
 keywords were not allowed as labels anymore ---
 I'd rather have the keyword ``fun'' replaced by Haskell's ``\'',
 or by a real lambda in a suitable character set!)

My point with the ``f'' label is that I need it almost always:
For List.map, List.fold_right and friends I usually have
only simple list arguments, but complex functions,
and do not see the point why I should
let-define that function beforehand.
So I think it is most readable to write the following:

  let list3 = List.map list2
               ~f:(fun x -> .....
                            ... x ...
                            ..........) in
  ....

If the ``f'' label goes away,
then I need a labelled wrapper around the standard library.
If none is provided, I have to write it myself,
but I would much prefer to have a standard labelling of the standard library,
since this also provides the label-using community with useful conventions and
guidelines.

And I do find the labels in the standard library useful with OCamlBrowser --
I use that much more than my copy of the html-version of the OCaml manual!


Cheers,

Wolfram Kahl







And if the ``f'' label was to go away 
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Judicael Courant]

Jacques Garrigue a écrit :

> Sorry for Judicael, but I see no way to satisfy everybody with a single
> mode. (You don't expect me to just drop the label mode, and be happy
> with classic, no ?)
> 

No I can't. But I did neither expect you to remove labels from the
standard library: this would be just another way to drop labels, would
not it? :-)

> On the other hand Manuel expresses an opinion I've heard a few times:
> moving to label mode might be nice, if the price to pay was not so
> high.

I agree with this statement and that's why I would have prefered a
single mode: my problem is that with two modes I cannot say "ok, I am
just giving a try to the modern  style within this function/this file"
mostly because I have to choose classic vs modern for a whole file and
even for a whole project (as I do not want my Makefile to become a
nightmare because of labels).

Unfortunately it appears there is no mode that is "better" than both the
current classic *and* modern ones. So we need two modes.
Then, I am not opposed to have labels as the default mode (classic being
kept only for backward compatibility). However I wish there would be a
way to switch to this classic mode with a pragma (not only with a
command-line switch) so that it is easier to mix files in classic mode
and in modern mode in a given project (and if it is even possible, to
mix functions written in classic modes and in modern mode within a given
file). That would help moving eventually to modern mode. IMHO "There's
More Than One Way To Do It" is not necessarily a good slogan...

If I switch to labels, I would prefer changes to happen once. If you
remove labels from the standard library and leave them in third parties
libraries, either people won't use third-parties libraries (which would
be a pity) or they will come back later saying "labels are great! why
does the standard library lacks labels?". I would prefer the standard
library to have labels at the right places. IMHO there are still
possible improvements with respect to this issue. For instance in Map
you can find

val add : key:key -> data:'a -> 'a t -> 'a t
val find : key -> 'a t -> 'a
val remove : key -> 'a t -> 'a t

which is not really uniform (moreover, I never remember whether 
it is find : key -> 'a t -> 'a or find : 'a t -> key -> 'a so I would
like to have find : key:key -> 'a t -> 'a)

Judicaël.
-- 
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jacques Garrigue]

From: kahl@heraklit.informatik.unibw-muenchen.de

> I am a long-time label user (having started when OCaml still was
> Caml Special Light) and I have therefore gone through quite a few
> relabellings of the standard library.
> They never really hurt me (with a 50 module 30000 line project) ---
> only when labels went away, it meant trouble.
> (To make it clear: I ONLY use label mode and do not intend to switch.)

Indeed, when a label disappears you cannot commute anymore, and this
is a pain. I explained it in detail, but ...

> Jacques' words seem to indicate that there seems to be a
> complete unlabelling of the standard library in the works ---
> I must confess that I do not like that at all.
> (Is my interpretation right? I got the impression that
>  this was the only change intended for label mode.)
> Especially for the ``f'' label!

No, no. Nothing decided yet.
What I was thinking of was having a special module Stdlabels for
die-hard labelers like you and me, so you would just have to do
"open Stdlabels" at the top of your files, and get all the current
labels in Pervasives, List, String and Array.
There are not many labels left in other modules anyway :-(
One could say that this is still two modes, but at least the semantics
is the same.

> And I do find the labels in the standard library useful with OCamlBrowser --
> I use that much more than my copy of the html-version of the OCaml manual!

That's the most serious problem for me, and this is even why I first
devised this two-mode system a year ago, rather than using the
Stdlabels scheme. I hoped that people would enjoy ocamlbrowser like you
and me.
Surprisingly, they do not seem to use it that much... habits, lack of
advertisement ?

Cheers,

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jacques Garrigue]

Hello Judicael,

> Then, I am not opposed to have labels as the default mode (classic being
> kept only for backward compatibility). However I wish there would be a
> way to switch to this classic mode with a pragma (not only with a
> command-line switch) so that it is easier to mix files in classic mode
> and in modern mode in a given project (and if it is even possible, to
> mix functions written in classic modes and in modern mode within a given
> file). That would help moving eventually to modern mode. 

I asked for this pragma one year ago, but was refused it :-)
This should come from the users, they said.

> If I switch to labels, I would prefer changes to happen once. If you
> remove labels from the standard library and leave them in third parties
> libraries, either people won't use third-parties libraries (which would
> be a pity) or they will come back later saying "labels are great! why
> does the standard library lacks labels?". I would prefer the standard
> library to have labels at the right places. IMHO there are still
> possible improvements with respect to this issue. For instance in Map
> you can find
> 
> val add : key:key -> data:'a -> 'a t -> 'a t
> val find : key -> 'a t -> 'a
> val remove : key -> 'a t -> 'a t
> 
> which is not really uniform (moreover, I never remember whether 
> it is find : key -> 'a t -> 'a or find : 'a t -> key -> 'a so I would
> like to have find : key:key -> 'a t -> 'a)

So bad you didn't say it one year ago :-(
In ocaml-2.99, this was the case, but I had to remove labels on find
and remove against my will :-)

Remark that this might suggest yet another evolution:
keep classic and label mode as they are now, but add more labels in
the standard library (revert back to the old labels ?)

Jacques

P.S. It's friday night here, so I'll join back the discussion on
monday.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Francois Pottier]

Jacques,

> To keep the discussion open, here is a 3rd alternative, which involves
> making label mode the default mode, removing labels from the standard
> library (to keep compatibility with ocaml 2, that's paramount), and
> keeping a simplified classic mode for those who don't want to hear of
> labels at all.

> Would others enjoy moving to label mode at no cost (with libraries
> compatible with 2.x) ?  That is, would they be ready to write more labels
> when they use labeled libraries (like labltk) ?

This proposal sounds reasonable to me. But I'd support Judicaël and vote
in favor of a single mode. If the designer of a particular library chose
to include labels in its API, why should the user not comply? Who are the
people who `don't want to hear of labels at all'?

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

Hi Jacques,

> I hoped that people would enjoy ocamlbrowser like you
> and me.
> Surprisingly, they do not seem to use it that much... habits, lack of
> advertisement ?

I've tried OCamlBrowser on a few occasions, but its default behavior
is not quite intuitive enough for me to make it easier than looking
things up in the ocaml manual.  Here are a few reasons...

* I was never able to make the search functions work (which is precisely
what would have made it REALLY useful).  

* Since it uses pop-up windows, I find that my screen quickly fills up
with dozens of windows so that pretty soon I can't find anything or see
what I'm doing.  I wonder whether it would be worth considering managing
those windows yourself (i.e., enclosing them all in some big window that
you manage) and using some kind of tiling scheme to manage the space
better (with history/focus mechanisms to help recover recently viewed
stuff).

* Adding a path to the search path does not seem to have any persistent
effect, so every time I restart I have to manually fix up the paths to
find the lablgtk libraries, for example.  (I know there must be
command-line switches to do this, but I have never become a serious
enough user to look for them.  What I'm describing here is my experiences
as a naive, occasional user.)  

Even better would be to be able to switch easily *between* sets of paths
(something like Unison's named profiles), so that I could keep the
standard OCaml libraries in one pane, the lablgtk interfaces in another,
and the Unison sources in another.  When they're mixed together, the main
interface list gets too long and it's difficult to find things.

* One feature that I'd REALLY like would be the ability to click on a use
of an identifier and be transported to its def-site.  Similarly, I'd like
to be able to click on a declaration in a .mli file and be taken to the
corresponding definition in the .ml file.  I guess doing this right 100%
of the time might be hard (at least, it might require help from the
compiler), but I'll bet a simple guess would usually be OK.

        Benjamin


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

> This proposal sounds reasonable to me. But I'd support Judicaël and vote
> in favor of a single mode. If the designer of a particular library chose
> to include labels in its API, why should the user not comply? Who are the
> people who `don't want to hear of labels at all'?

I don't really have an opinion about whether classic mode, label mode, or
something else is best, but I'd like to add my strong support for having
just *one* mode that everybody uses.  

One thing to be careful of, though, is making the language a lot more
difficult to use for newcomers.  The present language design has the
advantage that people do not have to start out understanding labels to do
anything at all in OCaml -- they can learn about them much later, when
they start doing fancy GUI programming or whatever.

This property makes OCaml at the moment a much better language for
*teaching* than, say, Java, where there are about a dozen fairly deep
concepts that you have to understand before you can write even the
smallest program.  We use OCaml at Penn for teaching intro programming to
hundreds of undergraduates, and the main attraction is that you can write
significant programs in a tiny subset of the language.

     Benjamin
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Jean-Marc Alliot]

"Benjamin C. Pierce" wrote:

> One thing to be careful of, though, is making the language a lot more
> difficult to use for newcomers.  The present language design has the
> advantage that people do not have to start out understanding labels to do
> anything at all in OCaml -- they can learn about them much later, when
> they start doing fancy GUI programming or whatever.
>
> This property makes OCaml at the moment a much better language for
> *teaching* than, say, Java, where there are about a dozen fairly deep
> concepts that you have to understand before you can write even the
> smallest program.  We use OCaml at Penn for teaching intro programming to
> hundreds of undergraduates, and the main attraction is that you can write
> significant programs in a tiny subset of the language.
>

I completely support Benjamin opinion. We have exactly the same kind of problems
with our students and it would be a real pain if they had to learn labels from the
start.

So, my only strong wish is to still be able to use OCAML without having to know
anything about labels.

Note : I still find labels useful, especially in GUI bindings. And this comment is
in noway a criticism of Jacques Garrigue excellent work.


--
|             Jean-Marc Alliot          |
|  http://www.recherche.enac.fr/~alliot |
|         alliot@recherche.enac.fr      |



-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] ocamlbrowser [was labels]

[Brock]

I don't know if you've considered it before, but one idea I've toyed with
is an ocamlbrowser that looks and feels like a SmallTalk browser. The way
smalltalk browsers can be set up seems to fit Benjamin's requirements (as
well as my own).

Is there anyone else interested in a browser with a smalltalk-style
layout?

--Brock

PS
  Sorry my previous email replying about using Unix in toplevel didn't
answer the original question... someone else did so correctly though.

On Fri, 30 Mar 2001, Benjamin C. Pierce wrote:

|Hi Jacques,
|
|> I hoped that people would enjoy ocamlbrowser like you
|> and me.
|> Surprisingly, they do not seem to use it that much... habits, lack of
|> advertisement ?
....
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: ocamlbrowser [was labels]

[Jacques Garrigue]

Hi Benli,

Thanks for the feedback. This is what is needed to improve
ocamlbrowser :-)

> I've tried OCamlBrowser on a few occasions, but its default behavior
> is not quite intuitive enough for me to make it easier than looking
> things up in the ocaml manual.  Here are a few reasons...
> 
> * I was never able to make the search functions work (which is precisely
> what would have made it REALLY useful).  

That's pretty strange. You just have to input a defined name in the
entry field and press Search. Remark that it can take a long time when
you do it for the first time, since it must load all the .cmi in the
load path.
I would suggest you first read the 2 pages in the manual describing
how ocamlbrowser works, they should answer some of your questions.
In particular it explains how to search using type patterns.

> * Since it uses pop-up windows, I find that my screen quickly fills up
> with dozens of windows so that pretty soon I can't find anything or see
> what I'm doing.  I wonder whether it would be worth considering managing
> those windows yourself (i.e., enclosing them all in some big window that
> you manage) and using some kind of tiling scheme to manage the space
> better (with history/focus mechanisms to help recover recently viewed
> stuff).

As somebody else suggests, moving to a more smalltalk style navigation
would not be difficult. The current approach is mainly due to a
historical evolution, taking for first model the original camlbrowser,
where one window pops up for every definition!
In the current system you have one window per module, but one could
easily have a single window for all modules, as long as we do not have
recursive modules including each other...
I could include this as another style of UI.

Yet, I'm not 100% sure it would be better. The way you use
ocamlbrowser is different from a smalltalk browser, in that most of
the navigation is done through types: first look for a function, then
for the definition of the type of one of its argument, then for the
definition of a type appearing inside this definition... You often
want to see several things at once, and the current approach can help
there. Once in a while you press close all to collect the garbage.

> * Adding a path to the search path does not seem to have any persistent
> effect, so every time I restart I have to manually fix up the paths to
> find the lablgtk libraries, for example.  (I know there must be
> command-line switches to do this, but I have never become a serious
> enough user to look for them.  What I'm describing here is my experiences
> as a naive, occasional user.)  

Same syntax as ocamlc: use "ocamlbrowser -I +lablgtk".
If you define aliases, you can have several paths: that's the Unix
way.
I was only too lazy to develop a preference file format. That would
really be a nice utility module to share between Caml applications,
and it would help to have a compatible syntax. Could the unison
preference format be made an independent, reusable module ?

> Even better would be to be able to switch easily *between* sets of paths
> (something like Unison's named profiles), so that I could keep the
> standard OCaml libraries in one pane, the lablgtk interfaces in another,
> and the Unison sources in another.  When they're mixed together, the main
> interface list gets too long and it's difficult to find things.

This problem of list length is real. What you really want is to use
the same path (because it is also used for type checking), but to
restrict the list (and maybe search) to the part of the path your are
interested in. This could be done.

> * One feature that I'd REALLY like would be the ability to click on a use
> of an identifier and be transported to its def-site.  Similarly, I'd like
> to be able to click on a declaration in a .mli file and be taken to the
> corresponding definition in the .ml file.  I guess doing this right 100%
> of the time might be hard (at least, it might require help from the
> compiler), but I'll bet a simple guess would usually be OK.

You can. Because of the Amazon patent, this is not single click:
first type check the file you are browsing with Alt-t, then
double click once on the identifier to get to its interface
declaration, and then press either Impl (for implementation) or Intf
(for the interface, including comments).
It should be 100% correct.

Best regards,

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Re: ocamlbrowser [was labels]

[Benjamin C. Pierce]

> Thanks for the feedback. This is what is needed to improve
> ocamlbrowser :-)

I'm glad I asked -- I didn't realize OCamlBrowser was this cool!

[Warning: long and detailed response follows...  I almost took this
off-list, but eventually decided that others may have useful thoughts,
especially about the first couple of points.]

> I was only too lazy to develop a preference file format. That would
> really be a nice utility module to share between Caml applications,
> and it would help to have a compatible syntax. Could the unison
> preference format be made an independent, reusable module ?

We've worked pretty hard on the Unison preference handling stuff, and it
would be nice to see it packaged in a form that would be easy for others
to use.  However, it will take a little thought to figure out what is the
right way to "extract" it from Unison and make it stand on its own,
without splitting the code off into a separate version that is not the
one used by Unison.  The issue is that there are several low-level
utility functions that the preferences module gets from a standard Unison
utility module, but it probably doesn't make sense to export that module
verbatim to the whole world, since it also has quite a bit of
Unison-specific functionality in it.  Some refactoring is in order.

> As somebody else suggests, moving to a more smalltalk style navigation
> would not be difficult. The current approach is mainly due to a
> historical evolution, taking for first model the original camlbrowser,
> where one window pops up for every definition!
> In the current system you have one window per module, but one could
> easily have a single window for all modules, as long as we do not have
> recursive modules including each other...
> I could include this as another style of UI.
> 
> Yet, I'm not 100% sure it would be better. The way you use
> ocamlbrowser is different from a smalltalk browser, in that most of
> the navigation is done through types: first look for a function, then
> for the definition of the type of one of its argument, then for the
> definition of a type appearing inside this definition... You often
> want to see several things at once, and the current approach can help
> there. Once in a while you press close all to collect the garbage.

I think no single, simple mechanism is going to be right all the time.  

  * When I'm following a thread to get somewhere else, I want to reuse
    the same window that I'm looking at now.

  * When I'm looking at a piece of code and want to check something that
    it refers to, I want to pop that up in a different window that I can
    close when I'm done without disturbing the main one.  

  * Moreover, I may sometimes want to look at several modules together,
    and for this it would be useful to somehow attach them together so
    that they do not obscure each other, so that they can be moved and
    closed (and perhaps later re-opened?) together, etc.  This kind of
    "tiling" organization can sometimes also use screen space more
    efficiently.

Reaching a design that uses screen space optimally in all these
situations (and the ones I didn't think of) seems pretty hard, but
at least we could probably get a little closer.

Here's one possible design (I'm sure it can be improved).
   * Every navigation command comes in three forms:
       1) open a *new* window for the new information
       2) re-use *this* window to display the new information
   * Style (1) is the default.  Pressing SHIFT while clicking gets you
     style (2).  
   * A netscape-style "back" command can be used to restore the contents
     of the current (or temp) window to its previous state, or to close
     a window that you just created.  
   * Perhaps there chould be some way to make the SHIFT and CONTROL
     modifiers sticky.

A possible refinement: 
   * One window on the screen is designated the "temp window" (initially,
     there is no temp window; one is created the first time it is needed,
     and the same window is used thereafter).
   * Add a navigation style:
       3) use the *temp* window 
   * Pressing CONTROL when clicking gets you style (3).   
(I'm not sure whether this refinement is worth the trouble -- just having
mode (1) plus a "back" keystroke to close the new window when done might
be enough.)   

Neither of these ideas addresses the last point above, about sometimes
wanting to "tile" parts of the screen.  I have the impression that good
tiling schemes are hard to find.

A more minor comment: the window that pops up when you click a module
name is usually too short to show all of the things defined in that
module, which means there's almost always some scrolling involved in
finding what you want.  What about making these windows initially tall
enough to show everything (within reason), and providing a Minimize
button to save space if needed?

> This problem of list length is real. What you really want is to use
> the same path (because it is also used for type checking), but to
> restrict the list (and maybe search) to the part of the path your are
> interested in. This could be done.

What I'd *really* like is to be able to have several module listing
windows -- one for the standard OCaml libraries, one for the LablGtk
interfaces, one for the application program I'm browsing, etc.  

> > * One feature that I'd REALLY like would be the ability to click on a use
> > of an identifier and be transported to its def-site.  Similarly, I'd like
> > to be able to click on a declaration in a .mli file and be taken to the
> > corresponding definition in the .ml file.  I guess doing this right 100%
> > of the time might be hard (at least, it might require help from the
> > compiler), but I'll bet a simple guess would usually be OK.
> 
> You can. Because of the Amazon patent, this is not single click:
> first type check the file you are browsing with Alt-t, then
> double click once on the identifier to get to its interface
> declaration, and then press either Impl (for implementation) or Intf
> (for the interface, including comments).
> It should be 100% correct.

Wonderful!!

Wouldn't it be possible to make the typechecking step automatic -- do it
the first time someone clicks on an identifier?

> > * I was never able to make the search functions work (which is precisely
> > what would have made it REALLY useful).  
> 
> That's pretty strange. You just have to input a defined name in the
> entry field and press Search. Remark that it can take a long time when
> you do it for the first time, since it must load all the .cmi in the
> load path.

I don't remember what I was having trouble with before, but it does seem
to work fine now.

> I would suggest you first read the 2 pages in the manual describing
> how ocamlbrowser works, they should answer some of your questions.
> In particular it explains how to search using type patterns.

It would be nice if this information were somehow available from the
program itself.  (In Unison we do this by simply dumping the HTML
documentation into a text file using Lynx, cutting it up into sections
using some not-too-ugly hacks, and build a menu from these.  The result
is not as pretty as it might be, but it seems to get the job done.)
Another alternative is something like tool-tips.


Two last items for the wish list: 

  * It would sometimes be really helpful to be able to see a module
    dependency graph beginning from the present module, to get a sense of
    how things fit together. 

  * Some kind of outline mode for implementations would be nice.

Whew -- that should keep somebody busy for a while.

      Benjamin

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: ocamlbrowser [was labels]

[Francisco Valverde Albacete]

"Benjamin C. Pierce" wrote:

> Two last items for the wish list:
>
>   * It would sometimes be really helpful to be able to see a module
>     dependency graph beginning from the present module, to get a sense of
>     how things fit together.

Yes! Any graph! This is something I so much miss in Ocamlbrowser that I've almost
started putting it in several times already. Fortunately, I respect too much J.
Garrigue's work to mess with his code (or theory) and I have abandoned the project.

My own style of coding relies too much in piecewise construction of signatures and
modules and I would like to navigate the graph enormously... I can't help with
coding it, but I promise to make a thorough test of it if anybody obliges!

BTW I use ocamlbrowser very much indeed. Thanks Mr. Garrigue.

Regards,

        Francisco Valverde
        Univ. Carlos III de Madrid


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Re: ocamlbrowser [was labels]

[Michael Hicks]

Perhaps the browser could be merged with ocamldot?

http://www.research.att.com/~trevor/ocamldot/index.html

Mike

> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of Francisco
> Valverde Albacete
> Sent: Tuesday, April 03, 2001 1:44 PM
> To: bcpierce@cis.upenn.edu
> Cc: Jacques Garrigue; caml-list@inria.fr
> Subject: Re: [Caml-list] Re: ocamlbrowser [was labels]
>
>
> "Benjamin C. Pierce" wrote:
>
> > Two last items for the wish list:
> >
> >   * It would sometimes be really helpful to be able to see a module
> >     dependency graph beginning from the present module, to get
> a sense of
> >     how things fit together.
>
> Yes! Any graph! This is something I so much miss in Ocamlbrowser
> that I've almost
> started putting it in several times already. Fortunately, I
> respect too much J.
> Garrigue's work to mess with his code (or theory) and I have
> abandoned the project.
>
> My own style of coding relies too much in piecewise construction
> of signatures and
> modules and I would like to navigate the graph enormously... I
> can't help with
> coding it, but I promise to make a thorough test of it if anybody obliges!
>
> BTW I use ocamlbrowser very much indeed. Thanks Mr. Garrigue.
>
> Regards,
>
>         Francisco Valverde
>         Univ. Carlos III de Madrid
>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives:
http://caml.inria.fr

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Re: ocamlbrowser [was labels]

[John Max Skaller]

"Benjamin C. Pierce" wrote:
 
> Here's one possible design (I'm sure it can be improved).
>    * Every navigation command comes in three forms:
>        1) open a *new* window for the new information
>        2) re-use *this* window to display the new information
>    * Style (1) is the default.  Pressing SHIFT while clicking gets you
>      style (2).

	No. Left button is 'same window'. Right button is popup menu.
It is the standard used in MS-Windows (eg in Windows Explorer).
Using this technique means only ONE mouse click for both cases,
in the second case the default is 'new' window, and requires no
mouse movement. Other options require movement. Neither option
requires any keyboard.

	Holding mouse still over active element pops up tooltip help
with extra information.

>    * A netscape-style "back" command can be used to restore the contents
>      of the current (or temp) window to its previous state, 

	Yes.

>  or to close a window that you just created.

	No: examine your browser. Back does nothing at the root.

>    * Perhaps there chould be some way to make the SHIFT and CONTROL
>      modifiers sticky.

	Modifiers should be avoided at all costs. They should only
be used for 'expert', 'dangerous' and 'user defined' functions. More
generally,
navigation should be possible with the mouse alone. The keyboard should
provide alternatives, but only be required for data entry and dangerous
functions. For example, by default 'search' should use the word the
cursor is on in an edit file and NOT require typing anything.
If an entry box is use, the default should support history by a drop
down list, 
again allowing no-keyboard operation in many cases. Again, see browsers.
 
> A possible refinement:
>    * One window on the screen is designated the "temp window" (initially,
>      there is no temp window; one is created the first time it is needed,
>      and the same window is used thereafter).
>    * Add a navigation style:
>        3) use the *temp* window
>    * Pressing CONTROL when clicking gets you style (3).
> (I'm not sure whether this refinement is worth the trouble -- just having
> mode (1) plus a "back" keystroke to close the new window when done might
> be enough.)

	No. This kind of refinement is definitely worth the trouble.

********************************************************************
  
	Here is a general comment. It is a serious bug of all current
GUI design that to make a functional GUI, one must take the basic
functionality like Ocamlbrowser today, and add more and more features
to control layout/style -- which have nothing at all to do with the
underlying functionality.

	A system for managing this complex problem independently
of the application is needed. Such systems exist, they're called
window managers on X systems, and they're quite archaic and
close to useless.

	I have designed and implemented an approach to a partial
solution (lots of qualifiers here!). It is called HWM, or
Heirarchical Window Manager. HWM uses a tree widget to represent
'containment' of application and sub-application level windows.

	Some of the windows used are containers: for example:
	a) multi-paned window (vertical, horizontal etc)
	b) notebook
	c) display

and some of the windows are application windows. These windows
are also containers by delegation to their parent.

	Using the tree widget, it is possible to move, iconise,
or destroy whole subtrees of windows. For example consider


	display
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

Here, 'module data' is a horizontally paned window, display is your X
windows
display. Ocamlbrowser-toplevel is a single non-container window, so we
have three top level windows at this point. I HATE that! So I (and NOT
ocamlbrowser) simply create a notebook:


	display
	  mybook
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

and then move the two module panes into it with drag and drop:


	display
	  mybook
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text
	  ocamlbrowser-toplevel

and now there are only two top level windows. Now, I want to see
both module data at the same time. So I right click on the 'mybook'
entry and select 'metamorphise/vertical paned window' and the notebook
is changed into a vertical paned window. I want to edit the text
of one module, so I just drag it out to 'display' to change it
to a top level window. Indeed, I have TWO displays, and at the flick
of a mouse, I can move the display to the second screen.

I designed HWM because I had a system much more complex than Ocaml
to browse: the complete text and code for a literate programmed
book. I needed the system to manage multiple ways of organising
information, which required a lot of kinds of 'summary' windows
at different levels of modularity.

So I have an interesting suggestion here. Instead of enhancing
Ocamlbrowser, REMOVE most of the window management (there isn't
much anyhow), and replace it with calls to a new HWM API.

Then build HWM. This will give the USER extensive control over layout
and window management, and that system will work for ANY compliant
application (not just Ocamlbrowser).

I have implemented HWM in iTCL and in Python, both using Tcl/Tk with Tix
for the GUI. (Tix is mandatory for the tree widget, which Tk lacks).
Tk has some problems reparenting a window to another display.
Ocaml has some problems with dynamic loading (required so HWM
can manage independent applications).

An Ocaml based  HWM implementation would be an interesting use of
classes. At the most abstract level, one writes only a management
system for a tree data structure. Subclasses are used to add
the tree widget modelling. Further subclassing is used to add
actual containers. Dynamic loading is used to add a menu of
applications.

HWM runs first, and can be used to create new containers and
launch user applications. The current design handles 
'add child to parent' but does not provide any control over ordering.
However, it is possible to change the state of the containment
tree by manipulating the other windows (and tricky to get the
synchronisation right). It is also possible to reorganise the tree
under program control (just by manipulating the abstract tree,
everything else works by method polymorphism).

Is anyone interested? Can a Tix binding be created easily?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Future of labels

[G Michael Sawka]

[As a small pre-script, I think it is really exciting to see all this
talk about language design (both theoretical and practical). I've been
lurking on the CAML list (and the labeling thread) for a  while,
trying to make sense of all of the discussion.]

Unless I am missing something, I don't see how you can reconcile
normal function application with commuting labeled arguments within
the current type system.  Consider:
  
  let sub_1 x y = <fun>  :  int -> int -> int
  let sub_2 ~x ~y = <fun>  :  x:int -> y:int -> int

The function sub_1 is a normal curried function that builds a closure
as the arguments are applied, and then passes the arguments all at
once to the underlying function.  The underlying closure data
structure can be thought of as an array since accesses are done via
position.

The function sub_2 is special.  It seems as if the labels "x" and "y"
are part of the type of the argument.  So, x:int is really a sub-type
of int.  But if this is the case, then "x:int" and "y:int" have
different types.  (Which certainly is consistent with how CAML handles
application of labeled arguments).

So, with commuting arguments, the given function signature doesn't
really give the whole story, we're really created two functions:

  x:int -> y:int -> int
  y:int -> x:int -> int

It seems to me that in order to support this type of argument
commuting, you end up creating the concept of a light-weight record
within the closure.

So, abstractly you end up with:
 
  [x:int; y:int] -> int

and the syntax "sub_2 ~x:5" merely sets the "x" field of the
light-weight record held in the closure to the value 5.  A call 
"sub_2 ~y:10" would set the field "y" to 10.  The special semantics of
this record are that when all the fields are set, it calls the
underlying function, and no field can be set twice.

This accumulation idea of values within the closure is equivalent to
the notion of the closure for sub_1 (since a call to "sub_1 5" sets
the 0th element in the array to the value 5).  The difference is that
in the first case, the underlying closure structure is accessed as an
array, and in the second case it is accessed as a map.

The conclusion?  These types of accesses *shouldn't* be mixed.  

But they are... which is what I think is creating all the confusion.
In label mode, the "map" concept is the dominant one.  In non-label
mode, the positional concept is dominant.  In CAML, it seems that they
are unified by hacks, whereby in non-label mode a label can be
associated with each position, and if a label is given, it is checked
for accuracy.  And, in label mode a position is assocated with each
label (based upon the order in which the arguments were declared) and
if no label is given the position can be used to do the mapping.  But
in general, I think this unification is a bad idea... (e.g. label
mode's ability to commute labeled and unlabeled arguments!)

What is needed is either to choose one mode or the other (which cannot
be done -- as it seems that the one thing this discussion has agreed
on is that we can't agree on one particular mode).  Or, a syntax
(yuck) needs to be created to allow function signatures to clearly
mark which closure access mode is dominant.  Example:

  f  :  [x:int; y:int] -> z:int -> int

The first two arguments are mapped primarily by name.  Labels should
be used.  The third argument is mapped by position.  A label was
provided for clarity, but is not important.  Possible applications:

  f ~x:5 ~y:10 20
  f ~y:18 ~x:2 17
  f ~x:1 ~y:2 ~z:72

Unallowed applications:

  f ~z:8 ~x:2 ~y:10   <- z is a positional arugment, not
                         interchangeable with the mapped arguments
                         it must come 3rd.
  f 1 2 3             <- very bad style.  this should probably not be
                         allowed, or at least a warning should be
                         thrown indicating that you should not access
                         the labeled argument "x" by position.

Note also that the currying works properly (and intuitively):
  (f ~x:5) : [y:int] -> z:int -> int
  (f ~y:10) : [x:int] -> z:int -> int
  (f ~y:8 ~x:20) : z:int -> int

If you apply a labeled argument, it consumes on of the arguments from
the "[]".


                      -mike.


p.s.  Does this make sense, or am I missing something in the theory?


-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Markus Mottl]

On Wed, 11 Apr 2001, John Max Skaller wrote:
> Markus Mottl wrote:
> 	Doesn't this simply suggest that the library author should not
> se labels on functions with a small number of obvious arguments?

Right, but it also suggests that you as the library user shouldn't
place labels on your functions if you intend to use them as arguments
to unlabelled ones. This already reduced the number of labels quite
significantly.

> > But functions can be designed in a way such that positions will usually
> > match.
> 
> 	As I understand it, this will still work in commuting labelled
> mode by using labels more sparingly when defining functions.

Right again. So having labels all over the place is probably not very
advisable...

> > But I don't care about the benefits of commutation if the label names
> > don't match. 
> 
> 	This problem is no different from the same problem
> applying a functor. The names in the functor signature must match
> the argument. If they don't you have to 'remap' them by defining
> another module.

True, but I am not sure whether this is the same problem. It is usually
the case that modules are developed to match the signature of functor
arguments if they are supposed to be applied in this way. People define
many more functions than functors, using them in much more flexible ways.

> > In this case (which is, I fear, the usual one) I'll have
> > to write out all arguments and label names _anyhow_.
> 
> 	let f x y = y in
> 	fold_left f x l
> 
> works in commuting label mode if fold_left is defined without labels.

But it won't work if _f_ has arguments with labels! This is the problem
that I find annoying, because it prevents me from labelling functions
if they are supposed to be used with both fold_left and in other contexts.

> 	On the other hand:
> 
> 	w#set_press (fun ~x ~y ~time ~ctrl ~shift -> ... )
> 
> is fine for the set_press GUI function which accepts a callback
> with a lot of arguments. Aren't we arguing about how much labelling
> to do in a library, rather than whether using the labels _if provided_
> should be mandatory?

In the moment you use labels you force everybody else to use the same
label names. Not using labels at the call site is not an option, it's
mandatory (in label mode) if the definition also uses labels. The same
is true vice versa: if the library doesn't use labels, you also must
not use them or you have to work around it.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[John Max Skaller]

Markus Mottl wrote:

> Even if it seems right that labels scale better on functions that have
> many arguments (especially for ones of same type), we shouldn't neglect
> the fact that such functions are much, much rarer, both as definition
> and as application. We should certainly also consider statistical
> (information theoretic) aspects of the "OCaml-channel" when trying to
> find an "optimal code".

	Doesn't this simply suggest that the library author should not
se labels on functions with a small number of obvious arguments?

> But functions can be designed in a way such that positions will usually
> match.

	As I understand it, this will still work in commuting labelled
mode by using labels more sparingly when defining functions.

> But I don't care about the benefits of commutation if the label names
> don't match. 

	This problem is no different from the same problem
applying a functor. The names in the functor signature must match
the argument. If they don't you have to 'remap' them by defining
another module.


> In this case (which is, I fear, the usual one) I'll have
> to write out all arguments and label names _anyhow_.

	let f x y = y in
	fold_left f x l

works in commuting label mode if fold_left is defined without labels.

	On the other hand:

	w#set_press (fun ~x ~y ~time ~ctrl ~shift -> ... )

is fine for the set_press GUI function which accepts a callback
with a lot of arguments. Aren't we arguing about how much labelling
to do in a library, rather than whether using the labels _if provided_
should be mandatory?

> I don't know whether you are speaking of label mode, which I don't know
> too well.  With classic mode I don't find it so difficult: if I use any
> non-optional argument that comes after the default arguments, they will
> be bound to their defaults.

	In C++, defaults are given at the _end_ of the parameter list.
In Ocaml, they go at the beginning. This is confusing. :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Markus Mottl]

On Mon, 09 Apr 2001, John Max Skaller wrote:
> 	I don't think this is quite right. I'd put the general position
> like this: positional arguments are most useful when functions have
> a small number of arguments, since the notation for both definition
> and calling is compact. However, this style does not scale well:
> labelled arguments scale up better, and this _includes_ the case
> of higher order functions.

The difference between label mode and classic mode in this respect (HOFs)
is that in classic mode I can choose in most cases whether I eta-expand
and labelize whereas in label mode I am forced to eta-expand if labels
do not match (and they usually don't!).

Even if it seems right that labels scale better on functions that have
many arguments (especially for ones of same type), we shouldn't neglect
the fact that such functions are much, much rarer, both as definition
and as application. We should certainly also consider statistical
(information theoretic) aspects of the "OCaml-channel" when trying to
find an "optimal code".

> 	I'd like to explain the latter point. If you have a function
> accepting functions, some of which in turn accept functions,
> then your calling syntax is highly sensitive to perturbations
> in the definitions. I'd expect some of the parameters to have types
> such that the argument is a partial application of some other function,
> and given the large number of arguments hypothesis, positional currying
> will rarely
> be enough to reorganise the arguments anyhow. For consistency, one would
> use lambdas like (fun x y -> f a x b y) as arguments everywhere since
> they
> require less work to rewrite.

But functions can be designed in a way such that positions will usually
match. Nobody would define "f" in the way above if it is usually to be
used as a curried HOF.

> 	The big advantage of label mode for higher order functions
> is that label-style currying is more flexible by virtue of commutation,
> and therefore allows a more systematic way of passing arguments
> to higher order functions. The big _disadvantage_ here is that when
> this style of currying is not enough, one must resort to lambdas
> _anyhow_.

But I don't care about the benefits of commutation if the label names
don't match. In this case (which is, I fear, the usual one) I'll have
to write out all arguments and label names _anyhow_.

> 	Ideally, we'd like to have label mode, with some support
> for positional arguments by syntactic sugar (so there is only one
> mode and one explanation of the fundamental paradigm). For example:
> 
> 	fun x y -> ...
> 
> becomes
> 
> 	fun ~0:x ~1:y -> ...

This looks messy to me.

> BTW: the thing I find hardest to wrap my brain around is default
> arguments.
> I don't understand how to tell the difference between a partial
> application
> which doen't bind defaults and a complete application that does: it
> seems
> to be sensitive to whether all the non-default arguments are given
> or not, which seems fragile. Also, it doesn't seem possible in a partial
> application to bind a default argument to its default. This seems
> messy. Am I missing some simple explanation here?

I don't know whether you are speaking of label mode, which I don't know
too well.  With classic mode I don't find it so difficult: if I use any
non-optional argument that comes after the default arguments, they will
be bound to their defaults.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[John Max Skaller]

Markus Mottl wrote:

> One well-known reason for avoiding fully commuting labels is the problems
> they create with the use of higher-order functions. 

	I don't think this is quite right. I'd put the general position
like this: positional arguments are most useful when functions have
a small number of arguments, since the notation for both definition
and calling is compact. However, this style does not scale well:
labelled arguments scale up better, and this _includes_ the case
of higher order functions.

	I'd like to explain the latter point. If you have a function
accepting functions, some of which in turn accept functions,
then your calling syntax is highly sensitive to perturbations
in the definitions. I'd expect some of the parameters to have types
such that the argument is a partial application of some other function,
and given the large number of arguments hypothesis, positional currying
will rarely
be enough to reorganise the arguments anyhow. For consistency, one would
use lambdas like (fun x y -> f a x b y) as arguments everywhere since
they
require less work to rewrite.

	The big advantage of label mode for higher order functions
is that label-style currying is more flexible by virtue of commutation,
and therefore allows a more systematic way of passing arguments
to higher order functions. The big _disadvantage_ here is that when
this style of currying is not enough, one must resort to lambdas
_anyhow_.
For example, if you need to make the function 'pi' accepting unit and
returning float a binary function (ignoring both arguments) then
you can use the (classic mode) lambda

	fun x y -> pi ()

as the argument, but it cannot be done by either style of currying.

	Ideally, we'd like to have label mode, with some support
for positional arguments by syntactic sugar (so there is only one
mode and one explanation of the fundamental paradigm). For example:

	fun x y -> ...

becomes

	fun ~0:x ~1:y -> ...

that is, we use integers as the labels for a positional definition,
and in the call:

	f x y

we add integer labels to the unlabelled arguments by position:

	f ~0:x ~1:y

In this way, we have only strict commuting label mode, but we can still
use positional notation via sugar.

BTW: the thing I find hardest to wrap my brain around is default
arguments.
I don't understand how to tell the difference between a partial
application
which doen't bind defaults and a complete application that does: it
seems
to be sensitive to whether all the non-default arguments are given
or not, which seems fragile. Also, it doesn't seem possible in a partial
application to bind a default argument to its default. This seems
messy. Am I missing some simple explanation here?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Yaron M. Minsky]

I make heavy use of labels in classic mode both for the
extra type safety it provides and for documentation.  I
find it to be extremely useful, and would be sad to see
classic mode go. I've never felt a great need for commuting
of non-optional arguments.  LablTk, at least, seemed quite
usable in classic mode.

The idea of stripping labels out of the standard library
seems like a mistake.  The main thing I like about labels
is the extra safety they provide.  For example, the ~key
and ~data labels for the function in Map's iter is very
useful, particularly when the key and data happen to be the
same type.

I agree that having ocaml have one standard mode would be
best, if possible.  If there continue to be two modes, I am
strongly in favor of a pragma for specifying the mode on a
file-by-file basis.

I guess my ideal solution would be to have classic mode (or
some sound version of it) be the standard.  I see no great
value in commuting labels for non-optional arguments
(though I understand many disagree) and allowing novices to
ignore labels alltogether is enormously important --- ML is
weird enough for someone schooled in imperative languages,
without needing to understand labels as well.

(On another note, it would be lovely if one of these days
ocaml could move to something like the alternative syntax
shipped with camlp4.  There are a number of bits of the
caml syntax that are quite counterintuitive, most of which
are fixed with the alternative syntax.)

y

-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

OpenPGP Key at http://keyserver.pgp.com - KeyID 0x91F2C47C
Key Fingerprint:
   6838 FF4E 256C BD24 453E 6EEA 0FBE 6CF8 91F2 C47C
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Jacques Garrigue]

From: David Gurr <gurr@mrs.med.ge.com>

> > On the other hand Manuel expresses an opinion I've heard a few times:
> > moving to label mode might be nice, if the price to pay was not so
> > high.
> 
> That is my feeling.  I appreciate the "new" features in moderation.
> You type checker example is a good one as are the use of objects in
> ocamlop. But I like being able to bootstrap Ocaml from the (caml-light 
> equiv.) core langauge.  So I would like to remove labels from the
> standard library and the bytecode compiler code (I haven't looked
> carefully but I dont remember any there).

Indeed, the bytecode compiler is very conservative (and has to be so).
You will find some decorative labels in asmcomp (not mine).

The reason we allow labels currently in the standard library
(interfaces only) is that they are ignored in classic mode.
If they are no longer ignored by the default mode, they will of course
have to go.

> > So, you are rather a frustrated potential label mode user than a happy
> > classic mode user ?
> 
> Mostly a caml-light mode user but I use the ocaml extensions when they clean
> up otherwise messy code.  I got pretty frustrated when I wanted to
> compile (IMHO perfectly fine) 2.x code together with lablegtk.  If
> there was a 2.x to 3.x translator that added the labels for me, I would have
> been merely anoyed with the added verbage.  Removing labels from
> the standard library doesnt help if someone label-ifies another
> pre-3.00 library that I am using.

Always the same confusion: you don't have to use label mode for
lablgtk. Unison's GUI is rather large, and is completely written in
classic mode.

Concerning 3rd party libraries, this might of course be a problem, but I
would expect a much smaller impact. The authors will take responsible
decisions.

> Although I'm in agreement with maf, I dont think that I would be
> happiest with option 3.
> 
> I don't like having both label and classical.

Well, getting everybody to agree on a single mode is not going to be
easy... More seriously, I insisted that this nolabel mode would be
demoted, just kept for people with a fundamental allergy to labels
(why not?), or some relabeling magic.
The main problem with having two modes currently is that people
wrongly assume that they have to be in one to do the work, while it
can be done efficiently in both (independently of the libraries!).

> I think that label is best in the long run.
> 
> I think what I want are
> 
> -- label mode only
> -- restrained labels in the standard library
I think none by default is more reasonable.
But it might be nice to keep the labels in otherlibs like Unix.
They would of course stay in LablTk :-)

> -- a 2.x to 3.x translator
Not needed, as long as we remove labels from the standard library.
Really, such a translator is possible, but I don't like very much the
idea of a program fiddling with my code...
Remark that this would not be a 2.x to 3.x translator, but a classic
to label translator.
Anyway the translator only fixes your code, not your habits.
My intimate belief is that changing habits takes longer than changing
code, and by translating by hand you will learn faster :-)
(maybe not currently valid, because of the standard library)

> -- a (partial) 3.x to 2.x translator that complains & gives up when 
> there is not an obvious 2.x translation but good enough to de-label
> the standard library.
Possible again, but much more work: we must type the program, apply
some non-trivial transformations to it, and output it again. An early
version of olabl based on caml-light worked that way, but honestly
this was a pain.
Also, compiling optional arguments that way would produce really
obfuscated code.

> So what about ~f:?  I dont like ~f: and you do.  Suppose I had an
> editor that puts in the ~f: for me AND hides it so I won't see it
> in the cases when it is in the first arguement?  Or even better,
> the editor takes your code with the :) backwards arguement order,
> puts the arguements in the :) proper order and hides the ~f: 
> :) cruft.  Now I even happy with the most excessively label'd
> libraries.  I think.  

Well, this would still mean two modes. I don't think that classic and
label are bad in this meaning: they were design to interact properly.
But people are always going to meddle with each other, and you want to
be able to exchange code snippets by mail for instance.

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Arturo Borquez]

Jacques,
As a beginner in OCaml I could resume my experience as follows:
1) Labels on a local scope (within a specific app) are not so usefull as functions layouts are particular to that app and self documenting effect are acheived by using adecuate variable names.
2) The opposite is when working with big libraries, that is where labels with conmmuting and partial application capabitities play a great role. I have to say that for example LablGtk would be a real nightmare without conmmuting labels. So labels in commuting mode helped me a lot to do my first OCaml-GTK app. (When we are faced for the first time to a new library we all are BEGINNERS and spend a lot of time learning to deal with, so labels really helps).
So in my opinion labels are NECESSARY to deal with complex libraries. Moreover for me labels are really usefull IF_AND_ONLY_IF are in conmmuting mode.

Best Regards
Arturo Borquez


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Mattias Waldau]

In my previous job we used Visual Basic a lot. VB has
labels. Our coding standards required us to use labels
whenever two arguments had the same type, for example
2 string-arguments. This makes reading of the code
very easy, and reduces the risk of stupid bugs due to
wrong order of arguments.

As I see it, the main advantage of labels is readbility.

I also think the way that Ocaml does it is very good, VB
for example would require you to write 'f tree:=tree', 
whereas in Ocaml just writes 'f ~tree' to the function
'let f ~tree = ...'. Less to write which makes programs 
more compact and still readable.

As I see it

Advantages with 'classic mode':
- simpler, both for language implementor, emacs-mode 
  implementors, and for users (less to explain)
- more compatible with non-label code

Advantages with 'commuting mode'
- You don't have to remember the order
- You partially apply on any argument

I would say that the arguments for 'commuting mode' are
very weak. 

I can't value the possibility of being
able to partially apply on any argument. I would just
create a anonymous function that would change
the order of the arguments (which would be very
readable).

To not have to remember the order is only an
argument if you use a less capable IDE like Emacs.
All modern IDE's will automatically show the argument
list when you enter the function name, and thus you don't
have to remember the arguments, nor their order.

It would be very easy to make such a mode for Emacs for
Ocaml, especially since you only have to look in the
file itself before the current point, and in mli-files
that are 'Open'.

Maybe this mode already exists, I only use the standard
mode today, since I had problems with other modes on
Windows. If so, plz let me know.

/mattias

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Judicael Courant]

Hi,

I am personnaly a classic-mode user, except when I play with some GUI
libraries (which I have not much time to do). My wishes
about labels are

1) If there are several modes, the default one should be compatible with
ocaml 2.00 as I would prefer not to change my developments in Caml. On
the contrary, whether the current semantics of label is preserved or not
does not matter (for me at least).

2) There should be only one mode. I wish ocamlc has as few options as
possible.

3) If you can write labels then you should be able to commute them in
function application, otherwise there is little point in writing
applications with labeled arguments: you have to remember both the order
and the name of the arguments (though of course, it enhances the
security the type-checker offers...)

So, if I understand well, I would vote in favor of the solution your PS
provides.

[The following is probably off-topic and probably needs quite a lot of
work to be put in O'Caml but we can expect miracles from the Caml team,
can not we?]
A wish about optionnal arguments: I would use them a lot if they where a
bit more... optionnal, in the style of implicit parameters of
http://citeseer.nj.nec.com/lewis00implicit.html.

This would be really helpful when defining printers (where you have to
carry everywhere the channel on which you are printing), when you are
defining a type-checker (you must carry the current environment that is
unchanged in all your rules but the one about lambda-abstraction, ...).

Sincerly yours,

Judicaël.
-- 
Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/
(+33) (0)1 69 15 64 85
"Montre moi des morceaux de ton monde, et je te montrerai le mien"
Tim, matricule #929, condamné à mort.
http://rozenn.picard.free.fr/tim.html
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Mattias Waldau]

In my previous job we used Visual Basic a lot. VB has
labels. Our coding standards required us to use labels
whenever two arguments had the same type, for example
2 string-arguments. This makes reading of the code
very easy, and reduces the risk of stupid bugs due to
wrong order of arguments.

As I see it, the main advantage of labels is readbility.

I also think the way that Ocaml does it is very good, VB
for example would require you to write 'f tree:=tree', 
whereas in Ocaml just writes 'f ~tree' to the function
'let f ~tree = ...'. Less to write which makes programs 
more compact and still readable.

As I see it

Advantages with 'classic mode':
- simpler, both for language implementor, emacs-mode 
  implementors, and for users (less to explain)
- more compatible with non-label code

Advantages with 'commuting mode'
- You don't have to remember the order
- You partially apply on any argument

I would say that the arguments for 'commuting mode' are
very weak. 

I can't value the possibility of being
able to partially apply on any argument. I would just
create a anonymous function that would change
the order of the arguments (which would be very
readable).

To not have to remember the order is only an
argument if you use a less capable IDE like Emacs.
All modern IDE's will automatically show the argument
list when you enter the function name, and thus you don't
have to remember the arguments, nor their order.

It would be very easy to make such a mode for Emacs for
Ocaml, especially since you only have to look in the
file itself before the current point, and in mli-files
that are 'Open'.

Maybe this mode already exists, I only use the standard
mode today, since I had problems with other modes on
Windows. If so, plz let me know.

/mattias

-----Original Message-----
From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp]
Sent: Thursday, March 29, 2001 8:44 AM
To: mattias.waldau@abc.se; caml-list@inria.fr
Subject: RE: [Caml-list] Future of labels


From: "Mattias Waldau" <mattias.waldau@abc.se>

> Could you plz post a good argument for commuting labels.
> 
> Even if we have optional arguments, we could require that the
> arguments should be given in the correct order, and that
> optionals may be skipped.

Should I understand this as support for the classic mode ?
This is exactly what it allows/requires.
In fact it also allows commutation between optional arguments,
which I believe is not only useful but necessary, when you think that
some library functions have more than 10 optional arguments, and
nobody wants to remember their order. Compare with the pain they are
in emacs lisp.

Commuting for non-optional arguments is another problem.

I'm not sure I can give very convincing arguments, except for
functions that have more than 5 parameters, and were again you don't
want to remember their order. To be more precise, order alone is not
enough to remember the role of the arguments, and you probably don't
want to have to remember both name and order: one should be enough.

Since most functions have less than 5 non-optional arguments, this is
mostly a question of taste. I program always in this style, very often
permuting parameters in functionals. One specific advantage is with
respect to partial application: when defining a function you don't
have to carefuly design the parameter order to allow many partial
applications, since you can partially apply in any order.
If you want to have an idea of what it looks like, see the sources for
ocamlbrowser in otherlibs/labltk/browser. This is not very refined
code, but it uses commutation a lot.

Last, the concept of having everything commute is neat. Once you've
started to put enough labels, you really don't have to care about
parameter order anymore, at all.

Does this answer you question ?

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Markus Mottl]

Hello,

here are my two cents on labels (I am a classic mode user). Note that I am
not trying to make a suggestion on future directions, but only explaining
where I personally found them useful so far and where not and why.

On Thu, 29 Mar 2001, Jacques Garrigue wrote:
> In particular arguments for keeping a classic mode are:
> * having labels in the standard library
> * using decorative labels in one's own programs/interfaces
>   (something people asked for before ocaml 3.00)
> * allowing different styles depending on whether you care about
>   commutation or not

For me actually none of the above is an argument why I am a classic
mode user:

I don't use labels in the standard library, never use labels for
decorative purposes (identifier names of arguments should have an
intuitive name already) and do not need commutation (I do not even
commute optional arguments in my code unless this happens implicitly if
an argument is not provided).

To my disadvantage, I have always found it easier to remember numbers
(e.g. positions; phone numbers; ...) than names (e.g. identifiers;
names of people; ...). Thus, memorizing the order of arguments is in
most cases easier for me than remembering their label names. But this
may be only a habit that comes from constant training - maybe I'd become
a more social being through the use of labels ;)

Still, I find labels very useful for one specific purpose: optional
arguments. They are the most reasonable alternative to providing defaults
for function arguments that I know of. Libraries with functions that
require a huge amount of parameters for providing fully-featured
functionality (e.g. as in my Pcre and Lacaml libraries) only become
really convenient with optional arguments.

One well-known reason for avoiding fully commuting labels is the problems
they create with the use of higher-order functions. Since I make very
frequent use of those, they would make life with label mode quite hard,
I fear.

> Personally, if there is no support for classic mode as it is, removing
> it would simplify things. There are so few labels left in the standard
> library that removing them would not be a big pain.  The problem of
> other libraries, and particularly Unix, needs more work, but I would
> think it could be solved, if in particular people are really ready to
> write labels when they use 3rd party libraries.

It is surely necessary to settle on one mode soon: a split user community
using different programming styles is surely detriment to the further
growth of OCaml.

I'd be particularly interested in learning about the experience of people
who decided to move from classic mode to label mode or vice versa as
opposed to the experience of people who started out with one mode right
away. It is probably not so much the different modes itself that people
are afraid of but the effort of moving combined with the risk that the
other mode may not be as convenient as the one they are used to. Any
comments?

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels

[Chris Hecker]

My only request for label mode is that if there's no ambiguity, don't require the labels (meaning if I apply all the arguments and there are no labels, don't make me write them out anyway).  Basically, I'd like to be able to use libraries that require labels mixed with code that doesn't really need them but just uses them for documentation.

Commutation seems useful for thinks like labltk where there are zillions of parms, most of which aren't going to be filled in most of the time.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

RE: [Caml-list] Future of labels

[Jacques Garrigue]

From: "Mattias Waldau" <mattias.waldau@abc.se>

> Could you plz post a good argument for commuting labels.
> 
> Even if we have optional arguments, we could require that the
> arguments should be given in the correct order, and that
> optionals may be skipped.

Should I understand this as support for the classic mode ?
This is exactly what it allows/requires.
In fact it also allows commutation between optional arguments,
which I believe is not only useful but necessary, when you think that
some library functions have more than 10 optional arguments, and
nobody wants to remember their order. Compare with the pain they are
in emacs lisp.

Commuting for non-optional arguments is another problem.

I'm not sure I can give very convincing arguments, except for
functions that have more than 5 parameters, and were again you don't
want to remember their order. To be more precise, order alone is not
enough to remember the role of the arguments, and you probably don't
want to have to remember both name and order: one should be enough.

Since most functions have less than 5 non-optional arguments, this is
mostly a question of taste. I program always in this style, very often
permuting parameters in functionals. One specific advantage is with
respect to partial application: when defining a function you don't
have to carefuly design the parameter order to allow many partial
applications, since you can partially apply in any order.
If you want to have an idea of what it looks like, see the sources for
ocamlbrowser in otherlibs/labltk/browser. This is not very refined
code, but it uses commutation a lot.

Last, the concept of having everything commute is neat. Once you've
started to put enough labels, you really don't have to care about
parameter order anymore, at all.

Does this answer you question ?

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] Future of labels

[Jacques Garrigue]

Hello everybody,

A bit more than a year ago, we had a big "discussion" about presence
of labels in the standard library, and the existence of two modes
(classic and commuting labels).
The two modes were kept, but the number of labels were reduced.

Now that a more stable version was released, it may be time to assess
whether these choices were good, and what should be done in the
long-term.
As a minimum step, if the classic mode is to be kept, then its
semantics must be cleaned-up, because of the soundness problem I
exposed a few weeks ago, and also because its typing discipline is not
very well defined anyway.

Personally I see two possible directions.

(1) suppress the classic mode (and also labels in the standard library)
    advantages: now everybody can use commuting labels
    problems to solve:
      * need to provide alternative versions of some modules, were
        label mode users want to keep labels
        Not too difficult for the standard library itself, but what
        about other libraries. I particularly think of the Unix
        module, or user contributions that use labels.
      * what about people using "decorative labels", that is putting
        labels in the .mli files mainly, and only exceptionally in the
        implementation. i.e. real users of the classic mode.
      * transition for label mode users

(2) clean-up the classic mode
    This essentialy means giving a reduction semantics that matches
    more closely the typed behaviour. I give more details below.

Rather than getting immediately into a discussion about what is the
good solution (and this might be a 3rd one), it would be nice to now
really what people expect from labels.
In particular arguments for keeping a classic mode are:
* having labels in the standard library
* using decorative labels in one's own programs/interfaces
  (something people asked for before ocaml 3.00)
* allowing different styles depending on whether you care about
  commutation or not
* ...
Arguments for dumping it are:
* avoiding multiple styles
* desire for commutation, but do not want labels in the standard
  library
* ...

This would be nice if people could tell how they position themselves
on these, particularly if this is backed by experience.
Last year this discussion literally overflowed this mailing list, so
please speak in turn, and no need to repeat what the previous poster
said: this is not a vote, but a call for suggestions.

Personally, if there is no support for classic mode as it is, removing
it would simplify things. There are so few labels left in the standard
library that removing them would not be a big pain.  The problem of
other libraries, and particularly Unix, needs more work, but I would
think it could be solved, if in particular people are really ready to
write labels when they use 3rd party libraries.

Cheers,

Jacques Garrigue

P.S. Here are some possible rules for a better classic mode
(still 100% compatible with ocaml 2, and 99% compatible with the
current mode)

To keep the soundness, type annotations would have to intervene in
reductions. Before bashing about overloading, note that not inferred
types, but only syntactic type annotations are used, meaning that we
are still more or less working with an untyped semantics.

    (fun ~l:x -> e) ~l:v --> e[v/x]
    (fun ~l:x -> e) v    --> e[v/x]
    (fun ?l:x -> e) ~l:v --> e[Some v/x]
    (fun ?l:x -> e) e    --> (e[None/x]) e
    (f : l:t -> t') ~l:e  --> (f e : t')
    (f : ?l1:t1 -> ... ?ln:tn -> l:t -> t') e --> (f e : t')
    (f : ?l1:t1 -> ... ?ln:tn -> ?l:t -> t') ~l:e
       --> (f ~ln:e : ?l1:t1 -> ... ?ln:tn -> t')
    (f : ?l1:t1 -> ... ?ln:tn -> 'a) --> f

Advantage: we can now see at the semantic level that while
    (fun ~l:x -> e) ~l':e'
is not legal (stuck when l <> l'),
    let f ~l:x = e in (f : l':t -> t') ~l':e'
is legal (as it should be in classic mode, where different labels are
unifiable).
And of course this allows to discard optional arguments on the basis
of type information, solving the current soundness problem.

Problems:
 * this is a bit complex to understand in detail
 * type checking this relies on type information discrimination
   (but it should be added to the compiler anyway)
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr