Re: [Caml-list] Future of labels

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

[Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

More answers, and more prespectives.
That's all very nice.

Globally it seems that almost everybody would prefer a single mode.
This is also my point of view: staying with two "equal" modes is
confusing.

Originally this was an attempt to keep most of the progress made in
olabl (with label mode) for people with an olabl background, while the
classic mode was intended to be the main mode for people used to
ocaml. I hoped that maybe just a few people might switch to label
mode, and more importantly classic mode users would start using labels
in classic mode. This is the lack of progress in this last direction
that makes me thing this will not work as well as I hoped: there is
little point in having labels in the standard library if most 3rd
party libraries do not labelize their APIs. Then it is better to have
one single community adapt slowly.

This said, at last we got an answer from a "happy classic mode user".
At least my attempt was not completely absurd :-)

From: "Yaron M. Minsky" <yminsky@cs.cornell.edu>
> 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.

Thank you very much. I was starting to feel a bit depressed about the
outcome of the classic mode.

Still, if there is only one mode to keep, I think it is better to keep
the label mode, both because it is more powerful (commutation matters
for some users) and because it is better understood theoretically
(cf. the silly soundness problem in classic mode).

But if we manage well the transition, I believe we can keep most of
the advantages of classic mode, while getting labels out of the way of
beginners.

First, concerning the standard library, an idea would be to first
remove all labels from the default versions, but then add labelized
versions of some specific functions with a different name (adding a
"'" for instance).
I mostly think of: Pervasives.output', Pervasives.input',
Pervasives.really_input', Array.blit', String.blit';
and maybe also String.sub', String.fill', Buffer.add_substring',
Hashtbl.add', Map.add'.
Since their number is very small, this would not mean too much code
increase.
If we have these functions, then labellers would probably be happy
with a Stdlabels module containing just labelized version of List and
Array. (Keeping this compatibility module small is good to avoid
confusion).

However, while the duplication approach (at a function or module unit)
seems to be the only possible for the standard library, it would be
awkward for other libraries.
So the next question might be, are people ready to have some mandatory
labels in the Unix library? And how much?
Removing labels from the Unix library makes code less redable, and
more error prone, particularly since many arguments have the same
type. (See how easier it was to understand the last code snippet
posted on this list, where Unix.create_process was used with labels.)

The graphics library being more beginner oriented, I'm not sure
keeping labels there would be a good idea.

Last, there would still be a "nolabel" mode left, but this would be
mostly for technical reasons, and would not be explicitly supported
anymore after a transition period.

Jacques Garrigue

P.S.
A few other points from the orginal poster.
> 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.
Second request. If we stay with two "equal" modes, that may get
through.

> (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.)
That would be much harder for compatibility reasons.
Yet I understand camlp4 might get into the standard distribution.
Maybe not so nice for people attached to a unique mode, but if you
don't care that may become a real alternative.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Judicael Courant]

Jacques Garrigue a écrit :

[...]
> But if we manage well the transition, I believe we can keep most of
> the advantages of classic mode, while getting labels out of the way of
> beginners.
> 

I think beginners are not the problem. Explaining that you have labels
and that arguments may commute seems quite easy to me (of course I will
have to revise my teaching material, but I think that is another point).
At least it is an order of magnitude easier than explaining partial
application and currying (that is, if you do not consider optionnal
arguments).

To address Benjamin Pierce's concerns, I think teaching Java is another
problem as in Java you have no toplevel, so you must use the standard
library for doing I/O from the beginning. When beginning to teach Caml,
you can use the toplevel and therefore ignore the standard library for a
while (although I would not advocate for it, we have a "functionnal
approach" undergraduate course here that completely ignores currying
hence the standard libray for a whole semester!)

Rather, I am concerned with upward compatibility.

[NB: In the following, I often use "should". Please consider there is an
"In my humble opinion" before each of these uses]

You should not sacrifice the Right Way (tm) for compatibility. I mean,
the default way to write a program should be the Right Way (i.e. with
labels): you should encourage people writing a new program/module to use
labels (while allowing people to compile their old code with few
changes).

> First, concerning the standard library, an idea would be to first
> remove all labels from the default versions, but then add labelized
> versions of some specific functions with a different name (adding a
> "'" for instance).
> I mostly think of: Pervasives.output', Pervasives.input',
> Pervasives.really_input', Array.blit', String.blit';
> and maybe also String.sub', String.fill', Buffer.add_substring',
> Hashtbl.add', Map.add'.

So I think this is the Wrong Approach (tm). Instead, you should provide
an CompatLib (or WithoutLabels) compatibility module for old code and a
possibly a flag for compiling code with an implicit "open CompatLib". As
for other libraries, the Right Way is to have the default libraries with
labels also. Then either you suggest them to move to the Right Way, or
you provide them the needed CompatLibs. BTW, I guess writing a tool for
"unlabeling" a library would be quite easy, would not it? (parse the mli
of the labeled library, remove labels for producing the corresponding
unlabeled mli, and generate the wrapper ml file --- the only difficult
part is with concrete types). Such a tool would let you focus only on
the maintenance of one library. Moreover, after some time, you could
decide to remove support for CompatLibs while still let people
explicitly generate their own unlabeled libraries with this tool.

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, and ideas for library labelling

[Markus Mottl]

On Mon, 02 Apr 2001, Judicael Courant wrote:
> Jacques Garrigue a écrit :
> > First, concerning the standard library, an idea would be to first
> > remove all labels from the default versions, but then add labelized
> > versions of some specific functions with a different name (adding a
> > "'" for instance).
> > I mostly think of: Pervasives.output', Pervasives.input',
> > Pervasives.really_input', Array.blit', String.blit';
> > and maybe also String.sub', String.fill', Buffer.add_substring',
> > Hashtbl.add', Map.add'.
> So I think this is the Wrong Approach (tm). Instead, you should provide
> an CompatLib (or WithoutLabels) compatibility module for old code and
> a possibly a flag for compiling code with an implicit "open CompatLib".

I second Judicael's proposal. Having to type in those ' is surely annoying
and looks ugly.

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, and ideas for library labelling

[kahl]

Judicael Courant <Judicael.Courant@lri.fr> wrote:

> I think beginners are not the problem. Explaining that you have labels
> and that arguments may commute seems quite easy to me [...]

[...]

> You should not sacrifice the Right Way (tm) for compatibility. I mean,
> the default way to write a program should be the Right Way (i.e. with
> labels): you should encourage people writing a new program/module to use
> labels

I second this.


Now let me be a bit extreme: ;-)

Since labels are recognised as the way to go,
the next release will most likely have different labellings and
different label semantics (at least for previous classic mode users)
than the last release.


The situation is then very simple: ;-)

Everybody has the coice to continue to use the old version,
or to upgrade their source code to the new version.  ;-)

I have had this choice about ten times,
and I made the same decision every time!
(Project size: growing from about 30 to about 50 modules,
 10 to 30 thousand lines.)
(I hesitated only once, but that was exclusively for the change
 in the license conditions.)

Even when I needed to adapt a classic-mode third-party application
(for purposes not connected with the above-mentioned project),
my first move was to labelise it so it compiled in label mode
(or was it still OLabl at that time? I don't remember).

Given the average enthusiasm of the OCaml commnunity,
I am sure that the every OCaml user will immediately follow suit!
(In multi-person projects, this might be an excellent way
 to have the latest newcomer become acquainted with the whole source code
 in a single day ;-)


More seriously: Judicaël continues:

> So I think this is the Wrong Approach (tm). Instead, you should provide
> an CompatLib (or WithoutLabels) compatibility module for old code and a
> possibly a flag for compiling code with an implicit "open CompatLib". As
> for other libraries, the Right Way is to have the default libraries with
> labels also. Then either you suggest them to move to the Right Way, or
> you provide them the needed CompatLibs.

I think Jacques' proposal with the '-names is viable,
but I agree that from the design perspective, Judicaël's Right Way
should be preferred --- it may even be slightly more ``user-friendly''
than my extreme proposal.



Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

OK, now I have three answers calling for a more radical shift
toward labels :-)

Of course labels are the Right Way (yet, I don't care about trade marks).
Otherwise I wouldn't have suggested to introduce them in ocaml
in the first place.
Here is again a long explanation.


When labels were first introduced in Olabl, about 5 years ago, I did
not realize it fully: this was just an experiment in how many labels
you can put in a library, and how it feels to use. But then using it
myself, and having students use it, I came to realize that
_compulsory_ labels are really the way to go.  Of course optional
arguments are very nice for libraries, as everybody seems to agree,
but compulsory labels on non optional arguments are the real thing,
which change the programming experience (to speak Self'ish).
Commutation also matters, but again it is secondary to the fact that
all uses of a function will be coherently labeled. (By the way all
this discussion about labels being hard to understand to beginners is
of course trash. They clearly make understanding easier. But they may
make the teacher's work harder :-))

After various attempts at labelling, the conclusion was that you
should put as many labels as possible, with at most one non-labeled
argument per function, and very often none at all.
(By this standard the current labelling of the standard library is
just broken.)

Why such a frenzy of labels ? Nothing so surprising: natural language
is full of grammatical redundancies. You don't ask why you should put
an article before a name, or why a verb works with a particular
preposition. That's all defined, and it helps understanding each other.
Many people believe that since functional programming languages have a
mathematical basis, they should look like mathematical formulae, but
this is plain wrong: they should be redundant enough so that you
understand them as you understand a math course. You would be surprised
if the professor never reminded you of the meaning of a theorem when
using it, just because it was proved once!


So (compulsory) labels are the way to go. But what are labels in
ocaml? Most people just consider them as an extension, like objects
are. There are no objects used in the bytecode compiler, so there
should be no labels there, and as a result no (compulsory) labels in
the standard library.
Considering the history of Caml, this seems hard to refute.
The only new feature that made its way to the core is modules, and
the name changed from caml-light to caml special light then.
So if labels are to have the same role, people would expect a change
in the name of the language itself. I'm not sure this is really what
is needed now. (Wolfram talked about the freedom to stay with an older
version: this is exactly what happened for the many people who went on
using caml-light until recently)

Another example is Haskell: type classes became the main feature of
this language, so omnipresent that even the map function is
overloaded. A lot of comfort was gained, but the simplicity of the
core language was lost.


That was basically the dillemma when merging olabl into ocaml: olabl
was a different language, and I cannot see how all ocaml users could
suddenly be convinced to switch to olabl.
That's why I'm trying to make proposals that do not touch too directly
the core of the language. Just to make it easy to everybody.
I'm not sure I'm sacrificing the right way. What was the right way for
olabl is not necessarily the right way for ocaml. Yet, I would not
like to see labels limited to a small set of libraries, like LablTk
and LablGTK.


Also, these reactions surprised me a bit. I can very well see why
Wolfram pushes labels: he has as much experience as me in them, and
knows where they help. But Judicael and Markus had just said that they
were not using label mode. They may convince people much better if
they come back next week after having converted a few programs to
labels mode :-) Seriously, what labels lack currently is serious
users. (Well, there are some in Japan, but they are not very
outspoken).

Best regards,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Kipton M Barros]

As a beginning Caml programmer, I'm a fan of strong labels. Their utility
in documenting libraries like LablTk is obvious, but I find that even for
"simple" functions like List.fold_left they're helpful.

Having good label names both serves as a quick reminder of which arguments
are what, but also can help to remind what the function does.  In my
experience, I usually have to reference a function a few times before
getting it memorized; having labels can serve as a mental cue, speeding up
the process.

One label stumbling block I've had is some syntax confusion.  
Specifically, it took me some trial and error to figure out how to do:

let f ~x:y:int = y;;     and
let f ~(x:int) = x;;

Are these constructs mentioned in the tutorial?

Another minor point which may have been mentioned: sometimes when a label
is missing, the compiler can give cryptic error messages.  It might not be
generally possible, but it would be great if the compiler could sometimes
say "maybe missing label here:".

I seem to remember Markus Mottl mentioning earlier something about labels
hindering higher order programming (?).  If I got that right, I'm curious:
what are some examples?

Kipton



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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Patrick M Doane]

Hi Jacques,

I have worked with both the commuting label mode and classic mode.  My
experience has been that the labels can be useful in some places and not
in others.

I see that labels are useful when working with functions with a large
number of functions or default arguments. This problem can also be solved
nicely when the language supports shared field names among record types.
I think it would be much more useful to fix this problem than to focus on 
labelled arguments. Even better, support light-weight extensible records
with labels as first class values. Then we could build a really good
implementation of a relational algebra.

I also find that labels work very poorly with basic aspects of functional
programming. What is the "right way" to code these examples:

 1.  List.fold_right (List.fold_right IntSet.add) lists IntSet.empty

     How can I use labels here without eta expansion?

 2.  let (<<) f g x =  f (g x)

     What labels should be assumed about f and g?  Without any labels, the
composition operator will not be very useful.

As far as I can tell, the only sensible way for labels to exist in the
language is if they are completely optional.

BTW, if labels are to stay, can we do something about the syntax?  Hitting
the tilde gets really tiring on the hands.

Patrick

On Tue, 3 Apr 2001, Jacques Garrigue wrote:

> OK, now I have three answers calling for a more radical shift
> toward labels :-)
> 
> Of course labels are the Right Way (yet, I don't care about trade marks).
> Otherwise I wouldn't have suggested to introduce them in ocaml
> in the first place.
> Here is again a long explanation.
> 
> 
> When labels were first introduced in Olabl, about 5 years ago, I did
> not realize it fully: this was just an experiment in how many labels
> you can put in a library, and how it feels to use. But then using it
> myself, and having students use it, I came to realize that
> _compulsory_ labels are really the way to go.  Of course optional
> arguments are very nice for libraries, as everybody seems to agree,
> but compulsory labels on non optional arguments are the real thing,
> which change the programming experience (to speak Self'ish).
> Commutation also matters, but again it is secondary to the fact that
> all uses of a function will be coherently labeled. (By the way all
> this discussion about labels being hard to understand to beginners is
> of course trash. They clearly make understanding easier. But they may
> make the teacher's work harder :-))
> 
> After various attempts at labelling, the conclusion was that you
> should put as many labels as possible, with at most one non-labeled
> argument per function, and very often none at all.
> (By this standard the current labelling of the standard library is
> just broken.)
> 
> Why such a frenzy of labels ? Nothing so surprising: natural language
> is full of grammatical redundancies. You don't ask why you should put
> an article before a name, or why a verb works with a particular
> preposition. That's all defined, and it helps understanding each other.
> Many people believe that since functional programming languages have a
> mathematical basis, they should look like mathematical formulae, but
> this is plain wrong: they should be redundant enough so that you
> understand them as you understand a math course. You would be surprised
> if the professor never reminded you of the meaning of a theorem when
> using it, just because it was proved once!
> 
> 
> So (compulsory) labels are the way to go. But what are labels in
> ocaml? Most people just consider them as an extension, like objects
> are. There are no objects used in the bytecode compiler, so there
> should be no labels there, and as a result no (compulsory) labels in
> the standard library.
> Considering the history of Caml, this seems hard to refute.
> The only new feature that made its way to the core is modules, and
> the name changed from caml-light to caml special light then.
> So if labels are to have the same role, people would expect a change
> in the name of the language itself. I'm not sure this is really what
> is needed now. (Wolfram talked about the freedom to stay with an older
> version: this is exactly what happened for the many people who went on
> using caml-light until recently)
> 
> Another example is Haskell: type classes became the main feature of
> this language, so omnipresent that even the map function is
> overloaded. A lot of comfort was gained, but the simplicity of the
> core language was lost.
> 
> 
> That was basically the dillemma when merging olabl into ocaml: olabl
> was a different language, and I cannot see how all ocaml users could
> suddenly be convinced to switch to olabl.
> That's why I'm trying to make proposals that do not touch too directly
> the core of the language. Just to make it easy to everybody.
> I'm not sure I'm sacrificing the right way. What was the right way for
> olabl is not necessarily the right way for ocaml. Yet, I would not
> like to see labels limited to a small set of libraries, like LablTk
> and LablGTK.
> 
> 
> Also, these reactions surprised me a bit. I can very well see why
> Wolfram pushes labels: he has as much experience as me in them, and
> knows where they help. But Judicael and Markus had just said that they
> were not using label mode. They may convince people much better if
> they come back next week after having converted a few programs to
> labels mode :-) Seriously, what labels lack currently is serious
> users. (Well, there are some in Japan, but they are not very
> outspoken).
> 
> Best regards,
> 
> Jacques Garrigue
> -------------------
> 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] Future of labels, and ideas for library labelling

[Jacques Garrigue]

Hi Patrick,

Good to have a contradictory answer, since I was only attacked by more
extremist than myself.
My answer is frontal, but this does not mean that I'm discarding
your arguments. I just express another point-of-view.

> I have worked with both the commuting label mode and classic mode.  My
> experience has been that the labels can be useful in some places and not
> in others.
> 
> I see that labels are useful when working with functions with a large
> number of functions or default arguments. This problem can also be solved
> nicely when the language supports shared field names among record types.
> I think it would be much more useful to fix this problem than to focus on 
> labelled arguments. Even better, support light-weight extensible records
> with labels as first class values. Then we could build a really good
> implementation of a relational algebra.

I'm not really convinced of that. SML for instance has structural
records, and uses them in its basis library. You can look at the result
for yourself. For me it's only half the way.
* You cannot mix labeled and unlabeled arguments, whereas you often
  want to keep one unlabeled argument in your function.
  So you only get a weak form of commutation.
* I believe labels + currying give a nicer syntax. With tupled/record
  arguments it is much less natural to write a function inside a
  functional call.
* You would of course have to extends records with optional fields,
  with creates new problems of overloading.

Another way to see it is to compare Perl/Tk or Python/Tk with Tcl/Tk.
I think Tcl/Tk is nicer, even with all the ugliness of Tcl.

> I also find that labels work very poorly with basic aspects of functional
> programming. What is the "right way" to code these examples:
> 
>  1.  List.fold_right (List.fold_right IntSet.add) lists IntSet.empty
> 
>      How can I use labels here without eta expansion?

So, first let me see what your function is intending to do.
Ah, yes, your lists argument is a list of lists, and you want to put
everything into a set.
Now let's write it with labels
   List.fold_left lists ~init:IntSet.empty
     ~f:(fun set l ->
           List.fold_left l ~init:set ~f:(fun set x -> IntSet.add x set))
Note that I've switched to List.fold_left, which is tail recursive,
but you cannot do it with your approach.
I have also eta-expanded more than necessary, to make the code more
readable.
We can write something shorter if we use labels as they were in ocaml
2.99, before their trimming:
   List.fold_left lists ~acc:IntSet.empty
     ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
Now, which is the more readable program, this one or yours.

Honestly, using folding functions without labels and eta-expansion is
just a nightmare to decrypt. For me it was really revealing to hear
from program transformation researchers in Haskell (who use fold for
their transformations) that they didn't use it directly in actual
programs.

Another problem about fold without labels is that I often use it
with two lists as parameters, and if you pass them in the wrong order
you have a well-typed utterly wrong program.
Can you tell at first sight if this code is correct or not?

List.fold_left (fun l x -> if List.mem x l then l else x::l) [1;2;1] []

>  2.  let (<<) f g x =  f (g x)
> 
>      What labels should be assumed about f and g?  Without any labels, the
> composition operator will not be very useful.

When composing, you are talking of transformer functions of one
argument. Most of them have no label anyway, so I don't see the
problem. Otherwise you eta-expand. Big deal.

> As far as I can tell, the only sensible way for labels to exist in the
> language is if they are completely optional.

My experience, and that of Wolfram Kahl, is that the eta-expansions
you have to do when labels get in the way are more useful than
harmful. Hard to grasp at the beginning, but clearly there is good
verbosity and bad verbosity. Making the labels apparent is generally
good verbosity.

> BTW, if labels are to stay, can we do something about the syntax?  Hitting
> the tilde gets really tiring on the hands.

Ah, this choice was a result of long, and sometimes tense, discussion
among developpers. I'm not sure we want to have this discussion again.

There are two solutions:
* use the olabl mode with camlp4, and you revert back to ocaml 2.99
  syntax. No need to type the ~ anymore. Neat hack.
* move the ~ on your keyboard to a more accessible place. This came up
  in the discussion, but we concluded that most editors give you ways
  to reassign keys.

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Patrick M Doane]

Hi Jacques,

Thanks for your quick response.  I appreciate what you are trying to do,
and evolving the language to include labels is a good thing.  I am really
undecided on the issue and have been trying to take a more conservative
approach since most discussion so far has been, as you say, even more
extreme.

On Tue, 3 Apr 2001, Jacques Garrigue wrote:

> > I see that labels are useful when working with functions with a large
> > number of functions or default arguments. This problem can also be solved
> > nicely when the language supports shared field names among record types.
> > I think it would be much more useful to fix this problem than to focus on 
> > labelled arguments. Even better, support light-weight extensible records
> > with labels as first class values. Then we could build a really good
> > implementation of a relational algebra.
> 
> I'm not really convinced of that. SML for instance has structural
> records, and uses them in its basis library. You can look at the result
> for yourself. For me it's only half the way.
> * You cannot mix labeled and unlabeled arguments, whereas you often
>   want to keep one unlabeled argument in your function.
>   So you only get a weak form of commutation.
> * I believe labels + currying give a nicer syntax. With tupled/record
>   arguments it is much less natural to write a function inside a
>   functional call.
> * You would of course have to extends records with optional fields,
>   with creates new problems of overloading.

I think that we're in agreement here.  Structural records like SML is a
start, but light-weight extensible records would address most of these
issues.

  - Labeled arguments are included in a record, and unlabelled arguments
are outside of the record.  And since they are light-weight, there is no
need to declare a type definition for the record. 

  - Labels and currying do give a nicer syntax.  On the other hand, not
having good support for records is a detriment to the syntax. Most
programmers coming to Caml will have an expectation that fields can belong
to more than one record.  Luckily, labelled arguments removes at least one
reason for light-weight records. 

  - Optional arguments can be addressed by having a value which
contains the default arguments which is modified by a record update
syntax.

> Another way to see it is to compare Perl/Tk or Python/Tk with Tcl/Tk.
> I think Tcl/Tk is nicer, even with all the ugliness of Tcl.

I agree.  Working with labels in the various GUI bindings has been
pleasant.  In fact, I remember reading a paper by Ousterhout where he
showed why strongly-typed languages were a bad idea.  All of examples came
down to showing how the programmer could type less in TCL but express the
same idea when compared to Java or C++.  But it took up the same amount
(or less) in O'caml.

> Note that I've switched to List.fold_left, which is tail recursive,
> but you cannot do it with your approach.

As an aside, it's unfortunate that Caml implements fold_left with the
"wrong typing".  It would be much more useful for fold_left to have the
same type as fold_right but still be tail recursive.  This would allow for
more natural folding compositions with other fold operators (e.g. Set). 

> I have also eta-expanded more than necessary, to make the code more
> readable.
> We can write something shorter if we use labels as they were in ocaml
> 2.99, before their trimming:
>    List.fold_left lists ~acc:IntSet.empty
>      ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
> Now, which is the more readable program, this one or yours.

Hmm... hard to say. Using this API, I would wonder why isn't there a label
for the list? It would be much simpler if every argument to a function had
to have a label.  I know this presents its own problems, but it adds to
the things one must remember for coding.

If the desire is to move towards labels, it may be worthwhile to consider

  let f x y z = ...

to be the same as

  let f ~x ~y ~z = ...

> Honestly, using folding functions without labels and eta-expansion is
> just a nightmare to decrypt. For me it was really revealing to hear
> from program transformation researchers in Haskell (who use fold for
> their transformations) that they didn't use it directly in actual
> programs.

I think it is a matter of background and taste. I quite frequently use
folding functions in actual programs, but this good information to be
aware of.

Regarding Haskell, what you say is surprising since I would classify
a common use of monadic binding as a folding function. For the operator
(>>=) which has type

       (>>=) :: m a -> (a -> m b) -> m b

if a and b are the same type than it is a folding over computation state.
This is certainly a common use in real programs.

> Another problem about fold without labels is that I often use it
> with two lists as parameters, and if you pass them in the wrong order
> you have a well-typed utterly wrong program.
> Can you tell at first sight if this code is correct or not?
>
> 
> List.fold_left (fun l x -> if List.mem x l then l else x::l) [1;2;1] []

This is a definite advantage of labels.  

Forgetting to use the label in commuting mode can lead to incredible
cryptic error messages. As discussed above, I like to use a variant of
list folding that gets the arugments in the "right" order and is
tail-recursive. I tried adding labels to the arguments to see what would
happen when they were omitted.  The result was pretty surprising: 

val listFold : f:('a -> 'b -> 'b) -> l:'a list -> acc:'b -> 'b

let cons x l = x :: l

listFold cons (listFold cons [5;4;3] []) [];; 

While this is a contrived example to reverse a list twice, not including
the labels gave this impressive type back from the compiler:

- : f:('a ->
       (('b -> 'b list -> 'b list) ->
        (f:('c ->
            (('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
            ('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
         l:'c list ->
         acc:(('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
'f) ->
        'g list -> 'h) ->
       ('b -> 'b list -> 'b list) ->
       (f:('c ->
           (('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
           ('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
        l:'c list ->
        acc:(('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
'f) ->
       'g list -> 'h) ->
    l:'a list ->
    acc:(('b -> 'b list -> 'b list) ->
         (f:('c ->
             (('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
             ('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
          l:'c list ->
          acc:(('d -> 'd list -> 'd list) -> int list -> 'e list -> 'f) ->
'f) ->
         'g list -> 'h) ->
    'h
= <fun>

I think this is more than enough to frighten me from using commuting label
mode.  The classic mode seems to give more sensible error messages.

Another language that I'm very familiar with that has labelled arguments
(in some sense) is Verilog.  Instantiation by named connection is
really crucial to using the language safely. Some observations though:

  1) There are no structures in the language, so some need of labelling is
needed.

  2) There is no partial application which makes it easier to give
intelligent error messages.

Hope there's some good thoughts in there for you.
Patrick

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

Hi Patrick,

This is only a point by point answer.

On labels vs. extensible records:
> > I'm not really convinced of that. SML for instance has structural
> > records, and uses them in its basis library. You can look at the result
> > for yourself. For me it's only half the way.
[...]
> I think that we're in agreement here.  Structural records like SML is a
> start, but light-weight extensible records would address most of these
> issues.
> 
>   - Labeled arguments are included in a record, and unlabelled arguments
> are outside of the record.  And since they are light-weight, there is no
> need to declare a type definition for the record. 

That's exactly what I was pointing as a weaker form of commutation:
labeled arguments commute between themselves, but they do not commute
with non-labeled arguments.

>   - Labels and currying do give a nicer syntax.  On the other hand, not
> having good support for records is a detriment to the syntax. Most
> programmers coming to Caml will have an expectation that fields can belong
> to more than one record.  Luckily, labelled arguments removes at least one
> reason for light-weight records. 

I know the lack of light-weight records is a pain, but we have already
two record-like structures in OCaml, and tuples. Predefined records
have their advantages, so this would mean adding yet another
structure. This may happen someday, but I'm not all that
enthusiastic.

>   - Optional arguments can be addressed by having a value which
> contains the default arguments which is modified by a record update
> syntax.

This handles only default arguments, optional arguments are more
powerful since their value may be computed at call time.


On proper labellings:
> > I have also eta-expanded more than necessary, to make the code more
> > readable.
> > We can write something shorter if we use labels as they were in ocaml
> > 2.99, before their trimming:
> >    List.fold_left lists ~acc:IntSet.empty
> >      ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
> > Now, which is the more readable program, this one or yours.
> 
> Hmm... hard to say. Using this API, I would wonder why isn't there a label
> for the list? It would be much simpler if every argument to a function had
> to have a label.  I know this presents its own problems, but it adds to
> the things one must remember for coding.

I think this is explained in the tutorial: you should not label the
object of the operation. Normally one learns that in elementary
school, but forgets it soon after, so it can be a bit difficult.
Requires some practice before it comes out naturally.

> Regarding Haskell, what you say is surprising since I would classify
> a common use of monadic binding as a folding function. For the operator
> (>>=) which has type
> 
>        (>>=) :: m a -> (a -> m b) -> m b
> 
> if a and b are the same type than it is a folding over computation state.
> This is certainly a common use in real programs.

I was only talking of list folding functions.
Labels are not the only way to improve readability. Infix operators
can also help.


On type errors in label mode:
> Forgetting to use the label in commuting mode can lead to incredible
> cryptic error messages.

The situation has improved a bit with 3.01.
Give it a try to see the difference. This is not perfect yet, but if
you see something clearly wrong you can send a bug report.

> As discussed above, I like to use a variant of
> list folding that gets the arugments in the "right" order and is
> tail-recursive. I tried adding labels to the arguments to see what would
> happen when they were omitted.  The result was pretty surprising: 
> 
> val listFold : f:('a -> 'b -> 'b) -> l:'a list -> acc:'b -> 'b
> 
> let cons x l = x :: l
> 
> listFold cons (listFold cons [5;4;3] []) [];; 
> 
> While this is a contrived example to reverse a list twice, not including
> the labels gave this impressive type back from the compiler:
[monstruous type]

This problem is specific to functions returning a polymorphic type:
if your arguments match none of the labels in the function type, they
will be seen as arguments to the result of the function, producing a
huge type by unification.

If you had tried on an instanciated typed, you would have got a more
reasonable answer.

# let rec listFold ~f ~l ~(acc : int) =
    match l with [] -> acc
    | x :: l -> listFold ~f ~l ~acc:(f x acc);;
val listFold : f:('a -> int -> int) -> l:'a list -> acc:int -> int = <fun>
# let cons x l = x :: l;;
val cons : 'a -> 'a list -> 'a list = <fun>
# listFold cons (listFold cons [5;4;3] []) [];; 
Expecting function has type
  f:('a -> int -> int) -> l:'a list -> acc:int -> int
This argument cannot be applied without label

When there is enough information, one can produce accurate error
messages.

> I think this is more than enough to frighten me from using commuting label
> mode.  The classic mode seems to give more sensible error messages.

In practice, I do not bump into this kind of errors very often.
In real programs, functions returning a polymorphic variable as result
are not so frequent.

> Another language that I'm very familiar with that has labelled arguments
> (in some sense) is Verilog.  Instantiation by named connection is
> really crucial to using the language safely. Some observations though:
> 
>   1) There are no structures in the language, so some need of labelling is
> needed.

Indeed, you will fell more directly need for labels in dynamically
typed languages.
But, while this may be true that labels are less needed from the
point-of-view of type safety, for documentation the need is identical.
Particularly in ML you don't write type annotations, and it is often
hard to follow the role of a variable in a program. Ocamlbrowser can
give you this information, but this does not replace information about
the role of an argument, which appears to be most needed when reading
a program.

>   2) There is no partial application which makes it easier to give
> intelligent error messages.

But partial application makes commutation more interesting :-)

Thanks for all these good points.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Xavier Leroy]

Wow, what a lively discussion!  I waited for a while before jumping
in, to see as many opinions as possible, but actually the arguments
put forward are pretty much the same Jacques and the rest of us
discussed while designing the OLabl/OCaml merger that gave OCaml 3.00.
So, let me recapitulate the ideas behind this design (at least as I
remember them).

1- We wanted labeled and optional function arguments to be an
extension of the Caml language (just like objects, classes, and
modules to a very large extent), i.e. something that does not affect
the core ML language, and remain backward compatible with earlier
versions of OCaml.  I think this is crucial for two reasons.  First,
it must be possible to learn and teach OCaml incrementally, by
successive layers of increasing complexity.  Second, we happen to have
users that develop significant applications in OCaml, and changing the
language in incompatible ways every other year is a sure way to piss
them off.  We get enough criticism and suspicion about OCaml "changing
all the time"...

(One consequence of this requirement is the ~label:arg syntax, because
the label:arg syntax of OLabl and OCaml 2.99 was causing syntax
ambiguities with type constraints ident:type and thus breaking
backward compatibility.)

2- With the strict label semantics of OLabl or OCaml with the -labels
option (if a label is given in the function definition/declaration, it
must be used in all applications of that function), the only way to
achieve backward compatibility (point 1 above) is to have versions of
the standard libraries that are totally unlabeled.  Otherwise,
long-time Caml users would have to change every call to List.map in
their code, and teachers would have to teach labels very early.

Of course, having standard libraries completely unlabeled kind of
defeats the purpose of labels (i.e. self-documentation of library
functions and additional safety and flexibility at applications of
these functions), so Jacques' initial proposal was to have two
versions of the standard libraries, one with labels and one without.
But we quickly realized this was unfeasible.  It's just too hard to
maintain two versions of the same libraries.  And everyone who writes
a Caml library and wants it to be used as widely as possible while
taking advantage of labels would also need to maintain two versions.

3- Thus the "classic mode" was born as a way to have only one
(labeled) interface to a library, yet not force users of this library
to use labels at applications.  I really liked this idea of Jacques,
because we can put labels in the library interface to self-document
it, yet remain backward compatible with code using the library without
labels.  Of course, users that want the additional safety of labels
can provide them at application sites, where they will be checked by
the type-checker.  To me, this is an excellent compromise: while I
usually don't put labels at application sites, I enjoy the additional
documentation provided by labels in module interfaces.

4- Since we did not want to trash the OLabl approach immediately, the
"commuting label mode" was introduced to 1- implement stricter
checking of labels, making them mandatory at application sites if the
function was declared with labeled parameters, and 2- support giving
labeled arguments in a different order than in the function
declaration.  Actually, a third mode was considered that would
implement strict label checking but disallow commutation, thus
ensuring that a given piece of code would be correct under both label
semantics ("classic" and "commuting"), but we weren't sure this had
enough value to be implemented.

5- We considered putting compiler pragmas to select the label mode
inside the source, possibly changing it around a piece of code,
instead of a per-file compiler flag.  OCaml currently does not have
this notion of pragmas, and it is not completely clear how they
interfere with, say, submodules (can I put the pragma inside a "struct"?
if so, what it its scope?).  So I decided to wait until the need for
such a pragma was really apparent.  But it can be done if really necessary.


A year or so later, I'm still convinced this design is the most
reasonable approach.  Yes, having two modes is not nice, but it is a
lot less bad than the alternatives.  If one mode must go, I think it's
the "commuting label" mode because of the backward compatibility issue
(point 1) and the fact that multiple versions of the libraries are
infeasible (point 2).  

So, the real questions I have for readers of this list:

- How many of you use the "commuting labels" mode?
- For those who use it, do you take advantage of commutation or
  do you use it mostly to benefit from strict checking of labeled
  arguments?
- What is worse in your opinion: having two modes or removing the
  "commuting label" mode?

Apologies for this long rant.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Judicael Courant]

Hi Xavier,

I understand the strong need for upward compatibility for O'Caml (note
however that the time I have spent porting programs from an O'Caml
version to another I negligible compared to the time I have spent
designing/writing/debugging them) but I disagree with you on some
points.

> 1- We wanted labeled and optional function arguments to be an
> extension of the Caml language (just like objects, classes, and
> modules to a very large extent), i.e. something that does not affect
> the core ML language, and remain backward compatible with earlier
> versions of OCaml.

I am not sure the case of classes and objects is the same as the case of
labels. As for modules I do not think they are an extension, even if
their power is underused. Map and Set for instance are useless if you do
not know how to apply a functor.

>  I think this is crucial for two reasons.  First,
> it must be possible to learn and teach OCaml incrementally, by
> successive layers of increasing complexity.

I already said I disagree on this. We have a one semester course here
that does not use the standard library because currified functions are
ignored. Does that mean you should remove currified functions from the
standard library?

> But we quickly realized this was unfeasible.  It's just too hard to
> maintain two versions of the same libraries.

Why? I do not see the problem with the tool I have suggested? (a tool
taking as input an interface file with labels and generating both the
interface file without labels and a stub implementation).

> And everyone who writes
> a Caml library and wants it to be used as widely as possible while
> taking advantage of labels would also need to maintain two versions.

I disagree with you: if I write an object-oriented library, I do not
feel the need to provide a non-object-oriented version of it. Users will
use objects or will not use the library. I think the same applies for
labels.

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, and ideas for library labelling

[Jacques Garrigue]

Salut Xavier,

I'm a bit surprised by your post. Yes this discussion is lively.
But it is calm, and we just try to find the Right Way. I'm not sure it
was the case last year, so I wouldn't discard this discussion as
useless.

> 1- We wanted labeled and optional function arguments to be an
> extension of the Caml language (just like objects, classes, and
> modules to a very large extent), i.e. something that does not affect
> the core ML language, and remain backward compatible with earlier
> versions of OCaml.  I think this is crucial for two reasons.  First,
> it must be possible to learn and teach OCaml incrementally, by
> successive layers of increasing complexity.  Second, we happen to have
> users that develop significant applications in OCaml, and changing the
> language in incompatible ways every other year is a sure way to piss
> them off.  We get enough criticism and suspicion about OCaml "changing
> all the time"...

This doesn't dispense us of trying to find a good solution.
Last year's change was 100% compatible, but I think that during our
discussions before the release we also talked of non 100% compatible
approaches. The real question is to make the cost of transition
neglectible, isn't it? And not to have to change again.

> 2- With the strict label semantics of OLabl or OCaml with the -labels
> option (if a label is given in the function definition/declaration, it
> must be used in all applications of that function), the only way to
> achieve backward compatibility (point 1 above) is to have versions of
> the standard libraries that are totally unlabeled.  Otherwise,
> long-time Caml users would have to change every call to List.map in
> their code, and teachers would have to teach labels very early.
> 
> Of course, having standard libraries completely unlabeled kind of
> defeats the purpose of labels (i.e. self-documentation of library
> functions and additional safety and flexibility at applications of
> these functions), so Jacques' initial proposal was to have two
> versions of the standard libraries, one with labels and one without.
> But we quickly realized this was unfeasible.  It's just too hard to
> maintain two versions of the same libraries.  And everyone who writes
> a Caml library and wants it to be used as widely as possible while
> taking advantage of labels would also need to maintain two versions.

I made some proposals to make the differences small enough that this
would be easy to maintain.
One important trouble yet is where is the limit between standard
libraries and other libraries.

> 3- Thus the "classic mode" was born as a way to have only one
> (labeled) interface to a library, yet not force users of this library
> to use labels at applications.  I really liked this idea of Jacques,
> because we can put labels in the library interface to self-document
> it, yet remain backward compatible with code using the library without
> labels.  Of course, users that want the additional safety of labels
> can provide them at application sites, where they will be checked by
> the type-checker.  To me, this is an excellent compromise: while I
> usually don't put labels at application sites, I enjoy the additional
> documentation provided by labels in module interfaces.

I sincerly hoped this would work.  Unfortunately, I see not very much
enthusiasm for the classic mode.

> 4- Since we did not want to trash the OLabl approach immediately, the
> "commuting label mode" was introduced

Huh, strange view of history.

> A year or so later, I'm still convinced this design is the most
> reasonable approach.  Yes, having two modes is not nice, but it is a
> lot less bad than the alternatives.  If one mode must go, I think it's
> the "commuting label" mode because of the backward compatibility issue
> (point 1) and the fact that multiple versions of the libraries are
> infeasible (point 2). 

I understand perfectly well point 1 (to a certain extent), but I'm not
so sure point 2 is really a problem if we are not too ambitious.

> So, the real questions I have for readers of this list:
> 
> - How many of you use the "commuting labels" mode?
I do. But I don't like votes.
> - For those who use it, do you take advantage of commutation or
>   do you use it mostly to benefit from strict checking of labeled
>   arguments?
Both, of course.
> - What is worse in your opinion: having two modes or removing the
>   "commuting label" mode?
I do not see where this alternative comes from.
Classic mode was designed as an interaction mode with label mode.
I wouldn't consider it very interesting on its own. (That's maybe its
main drawback)

Apologies for the short tempered reaction.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jean-Christophe Filliatre]

Jacques Garrigue writes:
 > Unfortunately, I see not very much enthusiasm for the classic mode.

First, let me say that probably most users of the classic mode are not
even aware  of what  labels are,  are not reading  this thread  or are
reading it but without participating. I  was one of the latter (and to
be more precise, we are many in that case in the team where I work).

But you want enthusiasm, I'll give you some.

I've written dozens of thousands lines of Caml code, and I'm currently
maintaining more  than one hundred thousands lines.  And I'm perfectly
happy with the  classic mode. I recognize that  labels may be helpful,
even necessary  in some particular  situations, but I don't  need them
*at all*  and I wouldn't like to  be forced to switch  to a compulsory
label-mode, nor to have to explain to the students the meaning of this
constraint.

You invoke  several arguments, in particular  documentation and static
checking of the code.

As far as  documentation is concerned, the classic  mode is enough for
that  purpose.  Personally,  I  use  a literate  programming  tool  to
document my programs (roughly in the way the ocaml standard library is
documented) and I don't use labels at all for a documentation purpose.

As far as static checking is  concerned, I agree that one can misapply
a function,  confusing for instance  the accumulator and the  value on
which to iterate.  But your arguments are not  convincing at all: your
version of the function building a  set from a list of lists was, from
my point of view, really uglier  than the initial one line version and
more  difficult for  me  to  read and  to  understand (in  particular,
because  I'm  familiar with  List.fold_left  and List.fold_right,  but
that's  rather  normal  to  be  familiar to  one's  favorite  language
standard library). You see, that's a question of programming style. So
why will  a few users  of labels impose  their programming style  to a
majority?

To  summarize, I  really think  you're underestimating  the  number of
users happy with the  classic mode and who would not like  to go for a
compulsory  label-mode.  They  are  probably  not  reading  that  (too
extremist) discussion anymore, actually.

Best regards,
-- 
Jean-Christophe FILLIATRE
  mailto:Jean-Christophe.Filliatre@lri.fr
  http://www.lri.fr/~filliatr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

[Caml-list] ocaml, java, rmi and jini

[Martin Berger]

hi there, i'm interested in integrating java and jini with ocaml. i 
understand that executing ocaml bytecode on JVMs might not be a 
good idea, but what about the other way around: executing java (byte
code) in an ocaml environment? and what about integrating java RMI
with ocaml? 

if all this was reasonably easy, it would be straightforward to write
one's distributed apps in ocaml and glue them together using jini.
of course it would be neater to have a DS framework like jini
in ocaml but that is probably not forthcoming anytime soon ...

i'd be interested in hearing people's opinion on this

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

Re: [Caml-list] ocaml, java, rmi and jini

[Chris Hecker]

>hi there, i'm interested in integrating java and jini with ocaml. i 
>understand that executing ocaml bytecode on JVMs might not be a 
>good idea

Have you seen this?
http://www.ocaml-programming.de/javacaml/manual/

I'd love to be able to either compile ocaml to JVM bytecodes (yes, I know it's hard) or have the javacaml system provide good access to some of the java libraries (some graphics, mouse/keyboard, simple UI, networking).  Is Gerd reading this?  I sent mail about the status of javacaml a while back, but haven't heard anything yet.

I'm interested in this because I want to write relatively simple web applets in ocaml, so javacaml would be find for me.  I assume anybody who wants to actually deliver a production app for a JVM would need a better solution.

Chris


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

Re: [Caml-list] ocaml, java, rmi and jini

[Gerd Stolpmann]

On Tue, 03 Apr 2001, Chris Hecker wrote:
>>hi there, i'm interested in integrating java and jini with ocaml. i 
>>understand that executing ocaml bytecode on JVMs might not be a 
>>good idea
>
>Have you seen this?
>http://www.ocaml-programming.de/javacaml/manual/
>
>I'd love to be able to either compile ocaml to JVM bytecodes (yes, I know it's hard) 
>or have the javacaml system provide good access to some of the java libraries
>(some graphics, mouse/keyboard, simple UI, networking).  Is Gerd reading this? 

Yes. 

>I sent mail about the status of javacaml a while back, but haven't heard
>anything yet. 

Sorry that I sometimes cannot reply immediately.

>I'm interested in this because I want to write relatively
>simple web applets in ocaml, so javacaml would be find for me.  I assume
>anybody who wants to actually deliver a production app for a JVM would need a
>better solution. 

Javacaml has very poor performance, and I think it is impossible to change
that. Even if we compile to Java bytecode directly. The point is that Java
bytecode is very restrictive due to its sandbox principle, and this makes it
impossible to map a different programming style to the code structure needed by
the JVM. For example, there is no "goto" in the JVM, but we need it for tail
recursion. Another problem are closures. There is no direct equivalent in Java;
you can only define classes that contain the implicit closure variables as
instance variables, and that have an "apply" method. This is a very expensive
mapping, and even if Java can deal with many classes, I don't believe that it
can deal with that many classes we would need to run Caml programs (usually
containing lots of closures).

Perhaps there is a scheme that maps from Caml to Java, but you would need
extensive program analysis to optimize the code.

Of course, it is still possible to use the current JavaCaml implementation, and
to extend it. However, I must warn you. "Some graphics, mouse/keyboard,
simple UI, networking" would require more performance than this emulation can
give you, even with execellent JIT compilers and fast CPUs. It's only several
thousand bytecode instructions per second.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml, java, rmi and jini

[Sven LUTHER]

On Tue, Apr 03, 2001 at 10:50:49PM +0200, Gerd Stolpmann wrote:
> Of course, it is still possible to use the current JavaCaml implementation, and
> to extend it. However, I must warn you. "Some graphics, mouse/keyboard,
> simple UI, networking" would require more performance than this emulation can
> give you, even with execellent JIT compilers and fast CPUs. It's only several
> thousand bytecode instructions per second.

Also javacaml don't work with the current ocaml, am i right in thinking this
Gerd ?

I suppose not too much work would be needed to solve this, as you only need to
add the primitives that were added to the standard lib between ocaml 2.0x and
3.01.

What are the other java alternatives for doing interactive web sites out of
ocaml bytecode, beside the cgi way that is.

Also, still no luck to ever see the ocaml plugin to netscape ?

Friendly,

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

Re: [Caml-list] ocaml, java, rmi and jini

[Gerd Stolpmann]

On Fri, 06 Apr 2001, Sven LUTHER wrote:
>On Tue, Apr 03, 2001 at 10:50:49PM +0200, Gerd Stolpmann wrote:
>> Of course, it is still possible to use the current JavaCaml implementation, and
>> to extend it. However, I must warn you. "Some graphics, mouse/keyboard,
>> simple UI, networking" would require more performance than this emulation can
>> give you, even with execellent JIT compilers and fast CPUs. It's only several
>> thousand bytecode instructions per second.
>
>Also javacaml don't work with the current ocaml, am i right in thinking this
>Gerd ?
>
>I suppose not too much work would be needed to solve this, as you only need to
>add the primitives that were added to the standard lib between ocaml 2.0x and
>3.01.

I've already done the necessary changes; the current javacaml distribution
works for ocaml 3. It was a bit more than adding the primitives, because ocaml
3 also introduced a new executable format.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] ocaml, java, rmi and jini

[martinb]

> >hi there, i'm interested in integrating java and jini with ocaml. i 
> >understand that executing ocaml bytecode on JVMs might not be a 
> >good idea
> 
> Have you seen this?
> http://www.ocaml-programming.de/javacaml/manual/

yes i have seen this, but it is the wrong way round for me.
i don't really need to run ocaml bytecode on a JVM. i want to 
develop (or have my students develop) distributed ocaml programs.
for various reasons i'd like to use jini as a "glue". for this
i would not really need to run ocaml on JVM, just invoce java RMIs
and execute simple java code under ocaml (and even that might
largely be avoidable)

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

Re: [Caml-list] ocaml, java, rmi and jini

[Xavier Leroy]

> hi there, i'm interested in integrating java and jini with ocaml. i 
> understand that executing ocaml bytecode on JVMs might not be a 
> good idea, but what about the other way around: executing java (byte
> code) in an ocaml environment?

As Jacques Garrigue said, it is feasible to write a JVM interpreter in
OCaml.  However, performance will not be great, and more importantly
most of the Java API libraries will be missing (because the JVM
interpreter will not be able to deal with native methods).

> and what about integrating java RMI with ocaml? 

That's not a bad idea.  I think it makes more sense to
interoperate between languages at the level of RPC/RMI, e.g. using Sun
RPC, CORBA, Java RMI, SOAP, or whatever, rather than interoperating at
the level of the virtual machines.  The problem here is that there are
so many standards to choose from...  Also, while, say, CORBA or SOAP are
relatively language-neutral, I don't know how Java-specific Java RMI is.

For completeness, let me mention a third possibility that I've been
working on and off (mostly off lately): interface OCaml and Java
through the OCaml/C interface and through Java's native interface.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

Last message before I make a needed pause, since I think lots of
people are already discarding this thread anyway.

I just repeat here what was my last proposal, since it was in the
middle of a mail, and some interested people may have not read it.
At least, they don't seem to have read it.
(It's only a personal idea.)

* make label mode the default mode
* keep a nolabel mode similar to current classic mode, but not
  allowing non-optional labels in function calls
* remove all labels from the standard library
* introduce a module StdLabels containing labelized versions of List
  and Array for labellers
* add some extra labelized versions of a few functions: 
  Pervasives.output', Pervasives.input', Pervasives.really_input',
  Array.blit', String.blit'
  and maybe also String.sub', String.fill', Buffer.add_substring',
  Hashtbl.add', Map.add'.

Remark that this does not change anything for people who didn't use
labels before: label mode is a conservative extension of ocaml 2, so
you don't even need to use the nolabel mode.

From: Jean-Christophe Filliatre <Jean-Christophe.Filliatre@lri.fr>
> 
> Jacques Garrigue writes:
>  > Unfortunately, I see not very much enthusiasm for the classic mode.
> 
> First, let me say that probably most users of the classic mode are not
> even aware  of what  labels are,  are not reading  this thread  or are
> reading it but without participating. I  was one of the latter (and to
> be more precise, we are many in that case in the team where I work).

Oh no, I was not underestimating your number; and I was indeed anxious
of getting advice from people like you. It was clear enough to me that
the answers I was collecting were not very representative.

> But you want enthusiasm, I'll give you some.
> 
> I've written dozens of thousands lines of Caml code, and I'm currently
> maintaining more  than one hundred thousands lines.  And I'm perfectly
> happy with the  classic mode. I recognize that  labels may be helpful,
> even necessary  in some particular  situations, but I don't  need them
> *at all*  and I wouldn't like to  be forced to switch  to a compulsory
> label-mode, nor to have to explain to the students the meaning of this
> constraint.

Thank you for your enthousiasm :-)
But by my category you are not an happy user of classic mode (even if
you are happy using it): you do not use any of the features of classic
mode that would be lost in this change, which are related to using
labels, but in a not-so-strict way.

Either you are ready to write labels when the writer of the library
has put some, and you just use the default mode (no labels in standard
libraries anyway). (That is, only if you need to use 3rd party libraries)

Either you have strong feelings against labels, and you use the
nolabel mode. The only problem is that examples coming with libraries
that use labels might need some easy rewriting.

If you could express yourself on this point, it would be interesting.
I am not at all convinced that this is an ideal solution, but I would
like to know what would bother you in it.

Best regards,
and thanks for ready my long mails

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Daniel de Rauglaudre]

May I ask a question? What is exactly the problem of having just one mode:
labels being optional *and* commutation mode? What is the problem, exactly?

1. if there are no labels, then the order is the order
2. if there are labels, then the parameters are indicated by the labels

Where is the problem? Could you give us examples?

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Claude Marche]

>>>>> "Daniel" == Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr> writes:

    Daniel> May I ask a question? What is exactly the problem of having just one mode:
    Daniel> labels being optional *and* commutation mode? What is the problem, exactly?

    Daniel> 1. if there are no labels, then the order is the order
    Daniel> 2. if there are labels, then the parameters are indicated by the labels

    Daniel> Where is the problem? Could you give us examples?

Dear all,

As Daniel, I do not understand where the problem is. My naive
understanding is the following: 

- either a function is defined without labelled arguments, and when
  calling it you have to provide arguments in the right order, and you
  may have a partial application if you don't provide all of them.

- or this function is defined with labelled arguments, possibly with
  default values like in LablTk, and for calling it you may provide
  the arguments in the order you like, omitting optional arguments if
  you like. And such a function call would be always considered
  non-partial, so that if you really want some kind of partial
  application then you have to eta-expand your function call.

Isn't this feasible? Isn't this enough for all purposes? If not,
does anybody could show a concrete example where this would not be
enough? 

If we need to vote, I vote for any solution that would keep future
ocaml versions compatible with 3.00. I do not want to use labels in
functions I write, but I don't mind to use labels for calling library
functions if the author as decided to use labels, like LablTk. And for
the standard library, I would really prefer to have no labels, I don't
see at all what we gain to have such labels ~f in List functionals.


-- 
| Claude Marché           | mailto:Claude.Marche@lri.fr |
| LRI - Bât. 490          | http://www.lri.fr/~marche/  |
| Université de Paris-Sud | phoneto: +33 1 69 15 64 85  |
| F-91405 ORSAY Cedex     | faxto: +33 1 69 15 65 86    |
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Gerd Stolpmann]

On Tue, 03 Apr 2001, Jacques Garrigue wrote:
>Last message before I make a needed pause, since I think lots of
>people are already discarding this thread anyway.

As I saw that many messages, I skipped the thread first. But I know it's
important... Sometimes it is better to wait until the direction of the
discussion becomes clearer.

I must admit that I never _decided_ whether to use classic mode or label mode;
I had my code base, and when O'Caml 3 was introduced I took the simplest way to
maintain my code. That was classic mode, because labels mode was incompatible
to previous versions of O'Caml. I began to use optional arguments, and from
time to time I also assigned labels to non-optional arguments. Even more seldom
I wrote labels at applications. (I _am_ an incremental learner.)

So I am a 50% classic mode user. 50% because I think labels are useful in
signatures (as documentation), but I can live without labels in
implementations. In my opinion, a (non-optional) "labels are comments in
signatures" mode would be right (i.e. nolabel mode). However, there is an
argument against this type of nolabel mode.

As a "library provider" I see the following problem with such a mode (and with
the current classic mode, too): I'm sometimes assigning too many labels, as in:

val f : ?optional:s -> nonoptional:t -> u

This is very natural if your main intention is documentation. But:

In classic and nolabels mode, the ~optional argument is really optional
because you don't apply the ~nonoptional argument with a label. But in labels
mode, you must pass the optional argument in order to execute the function.
Okay, the compiler prints warnings in such cases, but as a classic/nolabel
user I can ignore them. So I fear that libraries provided by users such me tend
to have pitfalls for labels users.

Because of this, I suggest that the compiler enforces that non-optional
labels are either turned on or off: If the .ml file is compiled with labels
turned off, the .mli file must not contain labels. If the .ml file is compiled
in label mode, it is accepted that the .mli file contains labels. So I am no
longer allowed to mix labeled declarations/definitions and unlabeled
applications in an insane manner.

Note that it is still possible to _use_ a labeled library in nolabel mode; in
this case all the labels are ignored.

>I just repeat here what was my last proposal, since it was in the
>middle of a mail, and some interested people may have not read it.
>At least, they don't seem to have read it.
>(It's only a personal idea.)
>
>* make label mode the default mode

Which mode is the default is very important. Users tend to keep the default
mode; so this mode will be used more frequent than the other mode. However, I
think we should not discuss about this point politically (i.e. who wins the
default mode wins the battle). Only a remark...

>* keep a nolabel mode similar to current classic mode, but not
>  allowing non-optional labels in function calls

As I already explained, I suggest to disallow non-optional labels in
abstractions and in signatures, too. This ensures that a library
written in any of both modes can be used in programs using the other mode in a
sane way.

>* remove all labels from the standard library

The standard library can remain labeled, because a nolabel user sees a view of
the standard library where all non-optional labels are stripped. But the stdlib
must itself be written in label mode.

>* introduce a module StdLabels containing labelized versions of List
>  and Array for labellers
>* add some extra labelized versions of a few functions: 
>  Pervasives.output', Pervasives.input', Pervasives.really_input',
>  Array.blit', String.blit'
>  and maybe also String.sub', String.fill', Buffer.add_substring',
>  Hashtbl.add', Map.add'.

This looks very ugly. 

>Remark that this does not change anything for people who didn't use
>labels before: label mode is a conservative extension of ocaml 2, so
>you don't even need to use the nolabel mode.

Fully agreed.

To summarize my suggestion:

- Two modes as before, but with clear roles: 
  - nolabels mode: Non-optional labels are totally forbidden. Neither
    abstractions nor applications nor mli files must contain labels. Optional
    labels are possible. When calling a library written in label mode, the
    arguments are identified by position nevertheless.

  - labels mode: Can remain as it is.

- Standard library: Is written in label mode, and has a labeled signature.

- Default mode: Is the nolabels mode because this mode is backward-compatible
  to O'Caml 2 and all 0% classic mode users (those who never use labels in
  their own abstractions nor in applications)

I think most current classic mode users can live with this. The difference
between these nolabels and labels modes is bigger than in the current
version of the language, as both modes emphasize their view on argument
handling. This may motivate people to switch from nolabels to labels mode,
because there is a real benefit from it. (You get the labels only if you
switch, even if your motivation for labels is code documentation and not the
possibility of commutation.)

A last thought: The nolabels mode should be called positional mode; "nolabels"
sounds very negative and one may associate with this name that its support will
end in the near future. (I also thought about a better name for label mode
because many people on the list were confused from the fact that it only changes
the meaning of non-optional labels. "Commuting non-optional labels mode" is too
long. But renaming the classical mode has an impact on that, too.)

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Ohad Rodeh]

List,
  I've been using OCaml for several years now, taught
with it, and helped build and maintain a very large (80KLOC) line
serious application with it. I think it is a truly
great language. 

My opinion with regards to Labels is that they are a fine
extension of the language, allowing better documentation and
type checking. However, using compulsory label-mode would require me
to change all my calls to Higher-Order functions in the standard
library (e.g. List.{map,for_all,exists,for_all2,exists2,...}).
I also use the Unix module regularly, and I wouldn't like the added
verbosity of labels. 

So, while labels are a find addition, they should stay out of the way
of ordinary usage, so they are in fact optional much like 
objects, polymorphic variants, and functors. 

All the best, 
   Ohad.

----------------------------------------------------------
orodeh@cs.huji.ac.il
www.cs.huji.ac.il/~orodeh




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

[Caml-list] Example of Ocaml-syntax problem with ;

[Mattias Waldau]

A misplaced ';' results in an error two expressions away.
The compiler compains at the last let in the following code.
It just says 'Syntax error'.

let _ = 1+2;

let _ = 2

let _ = 4

';' in Ocaml is really a problem for beginners, even if the rule
is rather simple: "Do not use any semicolons unless you really need
to separate expressions."

Would it be possible to make a better diagnosis on the semicolon 
above?

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

[Caml-list] Suspending threads

[Ohad Rodeh]

List,
  I'm trying to suspend a thread and then
have another thread wake it up. However, 
I can't find a suspend (nor a dual wake-up) function in 
the Threads library. 

  Any help? 

  Thanks, 
	Ohad.
----------------------------------------------------------
orodeh@cs.huji.ac.il
www.cs.huji.ac.il/~orodeh




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

Re: [Caml-list] Suspending threads

[Vitaly Lugovsky]

On Wed, 4 Apr 2001, Ohad Rodeh wrote:

> List,
>   I'm trying to suspend a thread and then
> have another thread wake it up. However,
> I can't find a suspend (nor a dual wake-up) function in
> the Threads library.
>
>   Any help?

  I'm using a condition for it. Suspended thread waits a condition
to be released, and other releases it after forwarding a request to
be executed in suspended thread.

  If you need an example, I can send you a threads
pool module used in my multithreaded server. It looks much better then
the same Java code. ;)

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

Re: [Caml-list] Suspending threads

[Xavier Leroy]

>   I'm trying to suspend a thread and then
> have another thread wake it up. However, 
> I can't find a suspend (nor a dual wake-up) function in 
> the Threads library. 
>   Any help? 

Right.  The reason there are no "suspend" and "resume" operations on
threads is that not all system thread libraries provide it, most
notably Posix threads.  There are very good reasons not to give these
operations to users, because they are extremely error-prone and make
little sense from a concurrency point of view: stopping a thread at
any time without its consent, e.g. while it is holding a mutex on
critical data, can deadlock the whole program.

The only legitimate uses for suspend/resume are 1- for low-level
services such as garbage collection and debuggers, and 2- to create a
thread in the suspended state, finish initialization, then let it
run.  But Posix decided these uses were not worth supporting :-)

As someone else replied, you should use a mutex / boolean reference /
condition variable combination so that the thread can voluntarily
suspend itself on the condition, and allow other threads to restart it
by signalling the condition.

The mutex / condition variable / predicate on shared state model
inherited from Posix may look heavy and restrictive at first sight,
but is actually quite flexible and less error-prone than alternatives.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Dave Mason]

>>>>> On Tue, 3 Apr 2001 10:52:12 +0200, Xavier Leroy <Xavier.Leroy@inria.fr> said:

> 1- We wanted labeled and optional function arguments to be an
> extension of the Caml language (just like objects, classes, and
> modules to a very large extent), i.e. something that does not affect
> the core ML language, and remain backward compatible with earlier
> versions of OCaml.  I think this is crucial for two reasons.  First,
> it must be possible to learn and teach OCaml incrementally, by
> successive layers of increasing complexity.

I agree.  Java and Ada are, to me, counter-examples of this approach.
Too much stuff you have to explain or tell students to ``just do this
magic.... don't worry why''.  I know that teachers of Java and Ada
(and labeled ocaml) feel otherwise, but I've done it, read their
explanations, have observed student response, and I remain un-convinced.

> Second, we happen to have users that develop significant
> applications in OCaml, and changing the language in incompatible
> ways every other year is a sure way to piss them off.  We get enough
> criticism and suspicion about OCaml "changing all the time"...

I agree here too.  I want ocaml to gain much wider adoption, and
occasional incompatible changes are not a sure recipe for this!  (On
the other hand, as far as I can see, all incompatibilities here would
be caught at compile time and would be quite obvious and easy to fix.)

> 2- With the strict label semantics of OLabl or OCaml with the
> -labels option (if a label is given in the function
> definition/declaration, it must be used in all applications of that
> function), the only way to achieve backward compatibility (point 1
> above) is to have versions of the standard libraries that are
> totally unlabeled.

> But we quickly realized this was unfeasible.  It's just too hard to
> maintain two versions of the same libraries.

I admit in advance I haven't looked at how the type-checking of labels
works in the compiler.  However it seems to me that it is simply a
compile-time thing, so a ``label-squashing'' .mli file should be able
to produce an image of a label-free library.  Maybe have a different
file extension - foo.cml and foo.cmi - for the two versions.  But they
would both use the same foo.cmo for the implementation.

> 5- We considered putting compiler pragmas to select the label mode

I think that if you want to keep 2 modes (and I find the arguments for
at least classic mode compelling), that a pragma should be seriously
considered.  Having a compiler switch makes Makefiles more complicated
to maintain.  (I like all variation of interpretation of a file to be
captured in that file.)  However, like everyone else I'd prefer a
single mode.

It seems to me that a label mode similar to the one (Arturo?) recalled
from his macro-assembler days would be more useful than either of the
existing modes (although some might like to keep a pedantic mode that
enforced use of labels).  To use everyone's favourite example, fold:
from analogy with scheme and long usage, I am comfortable with putting
the function parameter first, but I always have to stop and think
about the positions of the accumulator and list parameters, so it
would be extremely convenient if I could say, given a signature of:
	fold_right: ~f(~from_list:'a->~acc:'b->'b) -> ~list:'a list -> ~acc:'b -> 'b
any of the expressions:

	fold_right (+) [1;2;3] 0
or
	fold_right (+) ~list:[1;2;3] ~acc:0
or
	fold_right (+) ~acc:0 [1;2;3]
or
	fold_right (+) 0 ~list:[1;2;3]
or
	fold_right ~list:[1;2;3] ~acc:0 (fun x y -> x*3+y)
or
	fold_right [1;2;3] 0 ~f:(fun ~from_list:x ~acc:y -> x*3+y)

As I understand it, only the first 2 of these would be legal in
classic mode, and none of them would be legal in label mode.  Perhaps
there are good typing reasons why so few of these are legal, but to
me, labels would be much more useful like this than either of the
existing ways.

With the caveat that I haven't used label mode yet, I don't find
labels in type signature any more useful as documentation than the
signatures without them.  Their value is in application:
 1) to disambiguate parameters with the same type (this is a frequent
    annoyance in some work I'm doing in Java right now) and
 2) to allow sane use of functions with dozens of optional parameters
    (such as in lablTk).

Sorry if this re-opens old debates.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Francois-Rene Rideau]

Xavier Leroy, dans son post <20010403105212.A15700@pauillac.inria.fr> a écrit :
> It's just too hard to maintain two versions of the same libraries.

Couldn't camlp4 be put to good use to automatically extract
an unlabelled standard library out of the labelled one?
One library would either duplicate or wrap the other (working either
on both .ml and .mli or only .mli files).
Might be an interesting student project.
I don't mean that this is forcibly the Right Thing(tm) to do,
but at least, it's an option you might consider.
Of course, if the automated unlabeller becomes rigged with subtleties
and special cases, then indeed it might become a real bad idea
(or it might require some special purpose .mli annotation language).

Also, can you remind me what was the argument against having unlabelled
arguments be translated into labelled arguments according to the declared
order of arguments? e.g. "List.map func" being implicitly translated to
"List.map ~f:func" because f is the first (available) label?
I admit I haven't thought too much about the typing issues, but it looks
"natural" to me. That's the way some existing languages behave, as we've
been recently reminded, and it could solve the problem with unlabelled calls
to labelled functions.

Yours freely,

[ François-René VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System | http://tunes.org  ]
Procrastination is great. It gives me a lot more time
to do things that I'm never going to do.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Daniel de Rauglaudre]

Hello,

On Tue, Apr 03, 2001 at 03:43:00PM +0200, Francois-Rene Rideau wrote:

> Couldn't camlp4 be put to good use to automatically extract
> an unlabelled standard library out of the labelled one?

It could, but my opinion is that duplicating code is a bad thing, even
it can be done automatically. If the point is to duplicate things,
let's keep as it is, with two modes: classic and label.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Frank Atanassow]

I'm neutral on the future of labels; I'll use Ocaml in whatever form it takes.
But I just want to make some observations.

First, I think there is a tension on a larger scale between:

  * using labels in a library to distinguish arguments of functions with many
    arguments, and

  * refactoring a library to use a combinator-style approach as you often see
    in Haskell programs, for example with parsers, pretty-printers and GUI
    libraries.

Personally, I think the combinator-style libraries are more flexible and
more interesting than the more conventional monolithic approach, but in Ocaml
I feel there is a bias towards more traditional approaches to library
development which makes labels useful in practice.

Also, even when, like me, you prefer the combinator style, interfaces to
foreign programs---which all inevitably adopt the monolithic approach---are
usually arranged in two layers, the lower being a thin layer which just makes
the foreign functions directly available in the Ocaml language, and the upper
being a thick layer which decomposes monolithic operations into combinators,
and for writing the thin layer labels are still clearly a boon.

Second, in practice my biggest complaint about labels is the need to
eta-expand arguments of higher-order functions. I find it truly
annoying. Really. It just feels wrong that I have to relabel a function
argument, even if I'm not passing it any parameters. To me, this suggests that
labels do not belong in the type of a function, and rather that labels should
really only be an elaboration of the function application syntax. (So, instead
of one syntactic construct for application, namely juxtaposition, you have an
infinite number, one for each sequence of labels.) But that is a much more
fundamental issue, and is outside the scope of this discussion...

Lastly, I just have a small syntax suggestion.

Xavier Leroy wrote (on 03-04-01 10:52 +0200):
> (One consequence of this requirement is the ~label:arg syntax, because
> the label:arg syntax of OLabl and OCaml 2.99 was causing syntax
> ambiguities with type constraints ident:type and thus breaking
> backward compatibility.)

Patrick complained about the ~label:arg syntax. I think it is tiresome too. An
alternative is to force labels to be uppercase identifiers and get rid of the
leading tilde. This is not 100% backwards compatible, but I think it only
overlaps with the case where you provide a type constraint for a nullary
data constructor, which is quite uncommon. It also ensures there is no overlap
between keywords and labels, and looks quite suggestive for folds:

  List.foldr xs Cons:(+) Nil:0

Oh yeah, and I do think structural folds should be labeled by the constructors
of the datatype you are deconstructing. It is more meaningful than using
names like ~f: or ~funct:, which does not scale to the general initial
algebra case anyway. I have no suggestion for treating foldl-type things.

-- 
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Joshua D. Guttman]

I'm very grateful to Xavier Leroy for his posting.  I've been
listening to the labels discussion with increasing anxiety.  

I think we should make sure it remains possible to read and write Caml
code without added syntactic tangles; those tildes remind me of
whiskers.  More seriously, I find the syntax of Caml already fairly
obtrusive (versus Lisp and Scheme), and labels seem to me to make it a
good deal clumsier.  Why obstruct the fact that lots of code in a
language like OCaml is simply applying functions to arguments?  That's
the way it should be in a functional language.

Jacques Garrigue contrasts 

>   List.fold_right (List.fold_right IntSet.add) lists IntSet.empty

with 

>   
>      List.fold_left lists ~init:IntSet.empty
>        ~f:(fun set l ->
>              List.fold_left l ~init:set ~f:(fun set x -> IntSet.add x set))

and 

>      List.fold_left lists ~acc:IntSet.empty
>        ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))

To my eye, the original looks clean and compact.  The altered
versions?  They're not appealing to me.  

What are the arguments in favor of imposing labels on the rest of us?

1.  Optional arguments:  Well, this is occasionally useful, but I
    think not that often, at least in the kinds of programs I write.
    So the thing to achieve, in my opinion, is there should be no
    additional syntactic complication for writing or calling
    procedures that don't use them.

2.  Default values:  The Lisp-style solution to this was dynamic
    binding.  The default is stored in some mutable location; callers
    that want a different value store a new value and restore the
    original on return.  The language then provides some syntactic
    sugar (a macro) to make the alteration and restoration appear
    atomic, and to ensure that the default value is restored even in
    the case of non-local exit.  For instance, in the Yale dialect of
    Scheme, called T, there was a construct "bind".  I remember the
    manual saying, "Bind is syntactically similar to let but
    semantically very different."  The non-local exits were handled,
    within the "bind" macro definition, using unwind-protect, which
    was a primitive that would stipulate code to be run if the stack
    was unwound past the call site.

    I don't often need default values, but I expect that the
    equivalent could be rather easily implemented using exception
    handlers.  This would not affect any other aspect of the language.

3.  Documentation.  Why force every caller of a procedure to
    re-document the interface to the procedure?  That's what you're
    enforcing if the user has to write the labels.

    When it comes to documentation, there's no substitute for using
    the documentation itself.  Consider Emacs, the original
    self-documenting programming language (and it also contains a
    handy text editor :-).  Here the convention is that you document
    individual function definitions at a particular place; the
    "run-time system" then arranges for it to be very easy for users
    to access the documentation for every function (via C-h f).
    There's even completion if you type part of the name and want to
    see what function symbols start that way.  

    The etags program also provides a lot of support for people
    writing in other programming languages.  By the way, whatever
    happened to the OCaml mletags program?  I think it's been defunct
    since Ocaml 1.

    We could invent ways that people could get some of the benefit of
    the Emacs help system for Ocaml definitions documented in the
    manual.  I've been tinkering with an Emacs procedure that calls
    grep to find occurrences of a name in the manual, and W3 to
    display the corresponding HTML within Emacs.

    But the point here is to make documentation easily accessible, or
    to make it easy to find the site of definition for a procedure.
    It's wrong in my opinion to make the user repeat the documentation
    in the form of tilded labels at every use.  

4.  Commuting arguments.  This has to be a pretty specialized need,
    especially assuming programmers have easy access to documentation
    to find the intended order.  You're going to clutter a whole
    language to support this peripheral need?  


This language is complicated already.  It's extremely good, and I'm
doing my best to convert others to be followers of the cult too.  But
it's complicated, and we'll fight more losing battles to teach people
to use it if it becomes syntactically more cluttered.  Whether it's a
question of students (as in Benjamin Pierce's case) or colleagues (as
in mine), let's not block access to the really good (but subtle) ideas
in the language by complicating the way that it's written.

So my vote:  Please ensure that the programmer will not have to use
labels, except perhaps when using specialized libraries (e.g. for
GUIs).  

But to all participants, I'd like to say once more:  It's a splendid
language, the product of enormous intelligence and hard work, and I
appreciate being able to use it.

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop S119 
	202 Burlington Rd.		Tel:	+1 781 271 2654
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 3816

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Eric C. Cooper]

I have been using OCaml for about a year, having "converted" from SML,
and have only written a few thousand lines of code in it. I have only
used labels when forced to, in order to interface to labltk and lablgtk.

The label technology is an impressive piece of work -- it seems like a
very clean extension to the core language and clearly increases the
expressive power for a certain programming style. But the examples of
this style that I have seen, namely Tk and Gtk, seem to have been forced
on us by "foreign" packages.  Would a "native" library need labels as
badly? I would hope not -- it seems that OCaml should allow much nicer
interfaces than those in C and C++, but maybe I am just being naive.

So far, I see labels not as the "Right Way", but as a necessary evil for
dealing with complex real-world APIs.  Somewhat like a network firewall
-- you need more baggage to deal with the outside, but things can be
cleaner and more lightweight in an environment you control.

I don't agree that labels are valuable simply to document interfaces. 
Choosing names for interfaces is a very important part of software
engineering, and we already have to do it for types and values.  Having
to come up with good names (labels) for function parameters makes this
harder.  Having a lot of ~f, ~x, and ~list labels doesn't add enough
clarity, IMO, to compensate for the cluttering up of every function
call.

I have also noticed a "viral" aspect to labels.  If I start using a
labelled library, it tends to "infect" the client code that I write (in
order to gracefully call (f ~arg) for example).

Finally, I don't see continuation of two modes as a bad thing. Rather,
it is evidence of a healthy language with real users.  Look at gcc, with
its "-traditional" and "-ansi" modes.

Eric Cooper
ecc@cmu.edu
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[John Max Skaller]

"Eric C. Cooper" wrote:

> The label technology is an impressive piece of work -- it seems like a
> very clean extension to the core language and clearly increases the
> expressive power for a certain programming style. But the examples of
> this style that I have seen, namely Tk and Gtk, seem to have been forced
> on us by "foreign" packages.  Would a "native" library need labels as
> badly? 

	Yes, if it were implementing something as 'complex' as a GUI.
Many commercial applications embody much detail (even though they're
not intrinsically 'complex')

-- 
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, and ideas for library labelling

[John Max Skaller]

Jacques Garrigue wrote:

> >  1.  List.fold_right (List.fold_right IntSet.add) lists IntSet.empty
> >
> >      How can I use labels here without eta expansion?
> 
> So, first let me see what your function is intending to do.
> Ah, yes, your lists argument is a list of lists, and you want to put
> everything into a set.
> Now let's write it with labels
>    List.fold_left lists ~init:IntSet.empty
>      ~f:(fun set l ->
>            List.fold_left l ~init:set ~f:(fun set x -> IntSet.add x set))
> Note that I've switched to List.fold_left, which is tail recursive,
> but you cannot do it with your approach.
> I have also eta-expanded more than necessary, to make the code more
> readable.
> We can write something shorter if we use labels as they were in ocaml
> 2.99, before their trimming:
>    List.fold_left lists ~acc:IntSet.empty
>      ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
> Now, which is the more readable program, this one or yours.


	I'm a label mode supporter using classic mode exclusively.
I have no problem reading the original expression. Both the
label mode versions are harder for me to read due to a lot
of extra clutter. However, were the example more complex,
I think the label mode would win. More precisely: I didn't
actually _read_ the original example: I mentally pattern-matched
it in a single viewing. I had to scan the label mode versions
multiple times. 
 
> Can you tell at first sight if this code is correct or not?

	No, but in this case, I think the label mode version is
easier to check. I just 'guessed' what the classic mode
version of the expression did, i didn't deduce it: its a common
idiom I'm familiar with.
 
> My experience, and that of Wolfram Kahl, is that the eta-expansions
> you have to do when labels get in the way are more useful than
> harmful. Hard to grasp at the beginning, but clearly there is good
> verbosity and bad verbosity. Making the labels apparent is generally
> good verbosity.

	My take is this: if it is possible to recognize something
'as a whole' in a compact form, the compact form is best.
Otherwise, it is better to have enough redundancy that each part
is easily connected with the others while scanning the parts.
That is, classic mode is superior for simple things but doesn't scale.

	Here they are again, further reduced:

   fold_right (fold_right add) lists empty

   fold_left lists ~init:empty
      ~f:(fun set l ->
            fold_left l ~init:set ~f:(fun set x -> add x set))

The latter introduces extra names 'set' and 'l' and 'x',
where 'set' has two distinct definitions, in addition to
having the extra labels 'init' and 'f', which is 5 extra words.
It also uses 4 twiddles and 4 colons (~:), and an extra pair
of brackets, and takes three lines compared to one.
I find the layout disturbing. I'd write:

	fold_left 
	  lists 
	  ~init:empty
	  ~f:
	    (fun set l ->
	      fold_left
	      l
	      ~init:set
	      ~f(fun set x -> add x set)
	    )

which is 10 lines! Ugh.

On the other hand, for a callback from a GUI function, the more
longwinded style would probably help.

-- 
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, and ideas for library labelling

[Judicael Courant]

Jacques Garrigue a écrit :

> 
> Also, these reactions surprised me a bit. I can very well see why
> Wolfram pushes labels: he has as much experience as me in them, and
> knows where they help. But Judicael and Markus had just said that they
> were not using label mode. They may convince people much better if
> they come back next week after having converted a few programs to
> labels mode :-)

Ok. My reaction is mainly motivated by the fact that
1) I would like to have only one mode eventually (*)
2) I am ready to make a little effort on my side to achieve this

Now, I agree I should try a bit more labels before arguing in favor of
them :-) However, I just converted one 2kloc program I am working on in
a few minutes.

I did not switch to labels before just because
1) it was not the default mode and I am quite lazy
2) I have bad manners (I mean, I do not use labels) and my mother (I
mean the classic mode) did not forbid me to keep them

As a result I used labels once in the code I just converted when
defining a function, but never but never used them when calling any
function. I guess the same is true for other users.

> Seriously, what labels lack currently is serious
> users. (Well, there are some in Japan, but they are not very
> outspoken).

Ok, I am switching to -modern... After all, maybe the only change you
have to make for the moment to encourage people to use labels is to make
-modern the default mode and give a pragma for switching to classic
mode/to modern mode (in addition to the command-line flags).

Judicaël.

(*) I tried once to do some copy-paste from a code I found in labltk
examples into some of my code and had to switch to modern mode to use it
(making it compile in classic mode was a nightmare). Fortunately, my
code was quite simple so that the switch was easy...
-- 
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, and ideas for library labelling

[Chris Hecker]

I must admit to being a tiny bit lost in this labling discussion since I'm relatively new at caml and don't understand all the implications that people are talking about, but it appears people are now discussing enforcing typing labels even on labled non-optional parameters?  Documentation has been cited as a reason.  I would simply note that trying to force people to document their code simply doesn't work that well in practice.  However, forcing people to be verbose in spite of themselves does tend to amount to a mess.

I find OCaml pretty wordy as it is (no overloading being a big problem here, since the types all float into the names, as someone said), and making it moreso seems to me to be a mistake.  I also feel (like Patrick) that there are more important things (overloading, module recursion, generics) that need fixing than labeling right now.

However, I've only written maybe a 1000 lines so far, so we'll see how I feel when I've written more.

Chris

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

[Caml-list] Generics?

[Brian Rogoff]

On Mon, 2 Apr 2001, Chris Hecker wrote:
> I find OCaml pretty wordy as it is (no overloading being a big problem
> here, since the types all float into the names, as someone said), and
> making it moreso seems to me to be a mistake.  I also feel (like
> Patrick) that there are more important things (overloading, module
> recursion, generics) that need fixing than labeling right now.

I'm confused by your use of the term "generics", which I've seen in
another of your posts as well. Care to explain to the uninitiated? 

FYI, "generic polymorphism" is being used as a term to describe the kind
of overloading formerly called "extensional polymorphism", and that was 
probably influenced by CLOS/Dylan style generic functions with multiple 
dispatch. So generics are already overloaded enough, maybe you need to 
disambiguate :-). 

I don't find Ocaml wordy at all, but then I've used (and liked) Ada so 
it's probably just whatever you're used to...
 
-- Brian


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

Re: [Caml-list] Generics?

[Chris Hecker]

>I'm confused by your use of the term "generics", which I've seen in
>another of your posts as well. Care to explain to the uninitiated? 

I would definitely be one of the uninitiated as well.  :)

I should point out, as I said in my original post ages ago asking about the status of these features, that the generics thing is a little cloudy in my mind (as opposed to overloading and module recursion).  I'll mumble a bit and then maybe somebody with more of a clue can help out.

I first started thinking about this when I was trying to wrap my head around the difference between Caml style polymorphism and C++ templates.  Basically, if I write a sort routine in Caml, I need to pass in the comparator as a closure (not really, because </>/compare/etc. are polymorphic themselves, but hopefully you get the general idea).  Now, ignoring overloaded operators, in the C++ sort function you'd just type if(compare(a,b)) { ... } and the compare(type,type) function would have to be declared somewhere for the type you're sorting, but you don't have to pass compare to the sort.

There are pros and cons of both ways, as far as I can tell.  The Caml way lets you totally decouple the sort function from the code that calls it, whereas in current C++ implementations you basically need to have the sort function in a header file because it resolves compare() by name at the time of compilation.  On the other hand, in Caml I have to pass closures around all over the place, and for a simple case like compare(), I get a function call per comparison while the C++ case is easy to inline and generate optimal code as if the specific typed versions were hand written.

So anyway, I guess I want the best of both types (excuse the pun) of polymorphism/genericity.  I'm not exactly sure what "the best of both" looks like, however, so I'm not exactly sure what I want.  When I was thinking about this before, I ran across some good posts on the subject in the archive.

http://caml.inria.fr/archives/199803/msg00011.html
http://caml.inria.fr/archives/200004/msg00122.html

I guess a partial specification of "the best of both" would be that if all the information was available statically, then I'd like the optimal code to be generated, like C++.  If I stick a generic function into a datastructure or pass it as a closure, then I'm fine with the runtime checks that the second message above implies.

To take a slightly higher level view, I'd like to be able to do some of the generic programming stuff that Stepanov had in mind when he designed the STL.  I don't see how to do that without overloading and some kind of generic facility (or maybe overloading is enough, not sure).  Passing closures isn't really the same thing.

Vague enough for you?  :)

Chris


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

Re: [Caml-list] Generics?

[John Max Skaller]

Chris Hecker wrote:

> I first started thinking about this when I was trying to wrap my head 
> around the difference between Caml style polymorphism and C++ templates.  

	Ocaml generic functions require all arguments
to be passed in explicitly. C++ templates don't: some of the arguments
are passed implicitly. These arguments have to be looked up at
instantiation
time, in places depending on the types of the template type arguments.
For example:

	template<class T> T add(T t1, T t2) { return t1 + t2; }

Here, operator+ must be looked up when T is bound. It may be
a method of T, or it could be a function defined in the namespace
in which T is defined, or any base of T. Or it could be
defined in the context in which the template is defined.
Lookup is followed by overload resolution.

Consider even the case:

	template<class T> T add(T t1, T t2) { return t1.add(t2); }

and you see there is a constraint that T must be a class with
a method 'add' defined. The constraint is _implicit_.

Ocaml generic functions provide 'unconstrained genericity':
they work for ALL types. More precisely, if a call 'types'
correctly, then the function will work. This is NOT true
in C++, where it is not enough to know that a call types
correctly, since the instantiation can still fail
due to a failure looking up the implicit arguments
(or during subsequent overload resolution).

In general the use of implicit arguments is a bad, it breaks
the fundamental principle 'Explicit Interfaces' of Bertrand Meyer.

Note however that even Ocaml is 'weaker' than desired, since
interfaces cannot fully express constraints: type systems aren't
expressive enough. For example, a module may be:

	module type integer = sig
		type int
		val incr : int -> int
		val succ : int -> int -> bool
	end

and you can see the interface is inadequate, because the axiom

	succ x (incr x)

is not represented. This is relevant to generics too, since
a functor may require this constraint of its argument,
but it cannot be stated.

While one can live with constraints stated in comments
(by manually checking the constraints), Ocaml also has the
opposite problem. Some higher order generics cannot be defined,
and some of these CAN be defined using C++ templates.

Consider the generic 'map' which takes a container

	container<T>

and applies a function

	f:T -> V

to each element, producing a container

	container<V>

In Ocaml, there is one 'map' written per data structure. 
But 'map' is actually quite generic for a large class of containers.
In C++ you can write a template for map, but it relies on
overloading things like the begin() and end() methods used to
obtain the iterators.

In 'Functorial ML' (including FISh 2), there is a single 'map'
function that works for all data structures. So advances are
being made, to define 'even more generic'
functions than ocaml can support, and separately, work is being
done to allow constraints to be expressed (all obeying
the 'Explicit Interfaces' requirement).

[Note that Ocaml does have some ability to handle constraints]

-- 
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, and ideas for library labelling

[John Max Skaller]

Chris Hecker wrote:

> I also feel (like Patrick) that there are more important things 
> (overloading, module recursion, generics) that need fixing than labeling right now.

	I beg to differ. The current status is the result
of an incomplete merger of two communities, who have agreed
to use a common tool (ocaml with two modes) to unify the
ocaml development environment and provide a vehicle for
experiments leading to further unification of the language.

	The next step is surely to further unify our efforts,
by eliminating the duality in the languages that shared tool
processes. It is OK, IMHO, to introduce a duality in 
the libraries to do this. Now the theoreticians and implementors
can focus their attention better.

	The next step is to eliminate the duality in the libraries.
This will probably require some cleanups in the core language,
as well as some willingness for users to migrate.

	It is likely there will be a further cleanup.
So we have done step 1 of a four (4) step process.

	I've always thought finishing a job was a sensible
high priority.

-- 
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, and ideas for library labelling

[Jacques Garrigue]

From: John Max Skaller <skaller@ozemail.com.au>
>
> 	I beg to differ. The current status is the result
> of an incomplete merger of two communities, who have agreed
> to use a common tool (ocaml with two modes) to unify the
> ocaml development environment and provide a vehicle for
> experiments leading to further unification of the language.
> 
> 	The next step is surely to further unify our efforts,
> by eliminating the duality in the languages that shared tool
> processes. It is OK, IMHO, to introduce a duality in 
> the libraries to do this. Now the theoreticians and implementors
> can focus their attention better.

I think your analysis is correct here.
Note that I indeed started this discussion because the classic mode
had a theoretical problem: maintaining two modes with their technical
subtleties can become cumbersome.

Also, there is some room left to make the label mode more
user-friendly, like allowing you to omit labels in some unambiguous
cases.

> 	The next step is to eliminate the duality in the libraries.
> This will probably require some cleanups in the core language,
> as well as some willingness for users to migrate.

Well, after listening to reactions, I think this next step first means
reducing the number of duplicated labelized libraries, by admitting
that we don't need labels in all libraries: Objective Label tried to
offer a unified view with labels everywhere, but this is not practical
with OCaml.  In particular, traditional OCaml users are not willing to
migrate.

Then, further integration will only happen by natural adaptation:
the standard library will stay without labels, but outside of that
people choose the library whose design they like, be it with or
without labels.  This is no longer a problem of being in one or the
other community.

> 	It is likely there will be a further cleanup.
> So we have done step 1 of a four (4) step process.

I'm not sure I follow you here: step 2 is clean-up of the semantics,
step 3 is partial clean-up of the libraries (the remaining part being
really a problem of taste). I do not see what is left to clean-up
then: user libraries are designed by user themselves, we cannot edict
design directives for them.

Anyway, I agree with you: it may be time to do some clean up after the
merger, and this would improve the usability of the language.

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Fergus Henderson]

On 09-Apr-2001, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> wrote:
> From: John Max Skaller <skaller@ozemail.com.au>
> >
> > 	The next step is to eliminate the duality in the libraries.
> > This will probably require some cleanups in the core language,
> > as well as some willingness for users to migrate.
> 
> Well, after listening to reactions, I think this next step first means
> reducing the number of duplicated labelized libraries, by admitting
> that we don't need labels in all libraries: Objective Label tried to
> offer a unified view with labels everywhere, but this is not practical
> with OCaml.  In particular, traditional OCaml users are not willing to
> migrate.

I think it would be nicer to keep the labels in the standard library,
but allow the omission of explicit labels in calls (at least in cases
where this is unambiguous), as in the current "classic" mode.
Then those who wish to can use labels, and those who don't wish to
don't have to.

You could also have a "style-checking" compiler option to require labels
in calls if the function is defined with labels.  But unlike the current
"-labels" option, this option should just restrict you to a subset of
the language; it should not permit any programs that are not permitted
with the default options.

> Then, further integration will only happen by natural adaptation:
> the standard library will stay without labels, but outside of that
> people choose the library whose design they like, be it with or
> without labels.  This is no longer a problem of being in one or the
> other community.

One problem with this approach is that it leads to mixing of different
styles, since any given piece of code may contain calls to several
different libraries, and with your proposed approach the style used
in the caller is determined by how the callee is written.


[Note: I haven't actually written any non-trivial OCaml programs.
This is just my opinion based on experience with other languages.]

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[John Max Skaller]

Jacques Garrigue wrote:

> >       It is likely there will be a further cleanup.
> > So we have done step 1 of a four (4) step process.
> 
> I'm not sure I follow you here: step 2 is clean-up of the semantics,
> step 3 is partial clean-up of the libraries (the remaining part being
> really a problem of taste). I do not see what is left to clean-up
> then..

	Neither do I. But I've been a member of a Standards committee
for a long time, as has Fergus Henderson, and I'm sure he'd agree
that the practical experience is that further quirks and anomalies
usually emerge even after the best effort to finalise the design
of both a language and it's libraries. I added 'step 4' to the
list to account for this. :-)

	In fact, because of the very strong support for theory
and mathematics, the merger may be satisfactory after step 4,
rather than 5, 6, 7, or perhaps never :-)

-- 
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, and ideas for library labelling

[Chris Hecker]

>        I've always thought finishing a job was a sensible
>high priority.

Fair enough, especially if there's a spirit of compromise.  I think people (myself included) were simply reacting against the rather extreme suggestions that seemed to be going around from both sides.

Since I've been labeled (!) as a classic mode user in this discussion, I should point out that I am actually a label mode user since all of my ocaml code uses lablgl and labltk, and so I'm forced to use label mode.  I don't mind it, and I've actually written useful functions with optional arguments, commutation, and whatnot.  

My only request is still that if there's no ambiguity, don't require labels even in label mode.  

Of course, I reserve the right to request more features as I write more code.  :)  I've actually written a fair amount of "real" code over the past few weeks, so I'm starting to get more confidence in my knowledge of the language, but I'm still a long way off.

I'm a bit concerned by the currying-with-labels discussion, but I definitely don't understand all the issues there, so I can't weigh in with my [extremely valuable, I'm sure :) ] opinion.  I've run into this before, I think, but I can't remember the circumstances.  As I've been getting more comfortable with functional programming, I've been using currying more and more, and labels should definitely play nice with it.  I guess that means not forcing eta expansions very often just to rename parameters, among other things.  I wonder if that problem would go away if the "don't force labeling when unambiguous" feature was added...

Chris


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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

[ Disclaimer: you can safely skip this message if you are not
  interested in labels. It is about modalities of use for people who
  want them. ]

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.
People presented other languages more flexible with labels, but all
these languages had neither type inference nor first class functions.

Why is it so: type inference is based on unification. If you allow
discarding labels during unification, then the notion of what is a
labelled argument becomes fundamentally ambiguous.
In the most simplistic way (what is currently done in classic mode),
the type of a function variable will be non-deterministically taken
from the possible types inferred for this function. Imagine the
context gives both "f : a:int -> b:int -> int" and "f : b:int -> a:int
-> int". For labels to be really optional, you have to accept unifying
these two types, taking for the type of f one of these two.
This is not (too) ambiguous in current classic mode, since anyway
positional order is fixed, but if you allow commutation, then this is
not only the type which is non-deterministic, but also the result of
your function!

The situation might be improved a bit by using subtyping in place of
unification (which is known as very hard to infer!), but even then it
would still mean that the semantics use overloading, and we cannot
have a clean untyped semantics as is currently the case. Consider (f :
a:int -> a:int -> int). If we forget labels selectively, we can both
obtain (f : a:int -> int -> int) and (f : int -> a:int -> int),
meaning that the semantics of (f 1 ~a:2) depends on a notion of what
is the current type of f. Also, subtyping changes direction on left
sides of arrows, so this wouldn't be enough to make labels fully
optional.


So, is there no way out?
Not completely, if we accept to start from strict unification:
function types can be unified only if they bear identical labels.
This is the first option: starting from label mode.
But then, we can be more lenient:
  If only non-labelled arguments are given, and if their number
  matches the arity of the function, then the type checker
  automatically adds missing labels.
This is more or less what Chris Hecker is asking for.

What is nice about it: the semantics need not be changed, the only
thing the type checker does is adding labels in completely unambiguous
cases, where there is only one way to add them, and not adding them
would make typing fail. This makes efficient use of the fact order of
arguments in function types is fixed in ocaml (contrary to olabl).

This departs slightly from the pure untyped semantics for the source
program (semantics applies on a completed program), so that there
should be a way to turn on a warning, to make sure one's program is
complete, and pure semantics apply directly to the source. This
corresponds to the idea of having strict labels has a submode of
default mode.

Are there people who would _not_ be satisfied by such an approach?

A point of detail: this would _not_ solve the fold problem.  For two
reasons. One is that unification is kept strict, so the function you
pass to fold should have the right labels. And more specifically, you
wouldn't even be able to omit labels in the call of fold itself:
since fold has its return argument of polymorphic type, its arity is
not known, and we cannot tell whether an application is complete or
not. (One could accept this case on the ground that the ambiguity is
really minor, but the ambiguity exists.)
Anyway, I really think this discussion around fold and higher-order
functions is pointless: I'd rather let people use the labeled or the
non-labeled form according to their taste, than deciding what is the
right one for everybody. Frank Atanassow made a very interesting
contribution on this subject, on how the same person may both
appreciate programming by combinators (without labels), and also a
more imperative style (with commuting labels).

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Judicael Courant]

Hi,

Jacques Garrigue a écrit :
> 
> [ Disclaimer: you can safely skip this message if you are not
>   interested in labels. It is about modalities of use for people who
>   want them. ]
> 
> 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.
> 
I would vote for this one.


> * Extend classic mode with commutation, and keep labels in libraries.
>   Labels are kept optional.

The problem with this one is that if you choose to use labels, nothing
(at least for the moment) prevents you to write code in an inconsistent
style (putting labels at some places and forgetting them at some
others).

> 
> So, is there no way out?
> Not completely, if we accept to start from strict unification:
[...]

I can not really assess if this solution is good. However, it sounds to
me like a hack. I am rather suspicious of hack, be they clever as long
as they are not proven harmless (through a metatheoretical study). What
are the chances then that we experience bad behaviours of this hack
because of a lack of good theoretical properties?

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, and ideas for library labelling

[Jacques Garrigue]

From: Judicael Courant <Judicael.Courant@lri.fr>

> > [ Disclaimer: you can safely skip this message if you are not
> >   interested in labels. It is about modalities of use for people who
> >   want them. ]

> > So, is there no way out?
> > Not completely, if we accept to start from strict unification:
> [...]
> 
> I can not really assess if this solution is good. However, it sounds to
> me like a hack. I am rather suspicious of hack, be they clever as long
> as they are not proven harmless (through a metatheoretical study). What
> are the chances then that we experience bad behaviours of this hack
> because of a lack of good theoretical properties?

Just in case I confused anybody, this idea of allowing to omit some
labels is an extension of the label mode, not the classic mode. As I
explained, the classic mode itself is currently a terrible hack, and
trying to extend it is bound to fail.

For this idea, the reason it is more than  a hack is that it can be
proved unambiguous:
* the application is complete, and typing would fail otherwise
* ocaml's label mode does not allow unification between differently
  ordered function types, so that positional application is
  unambiguous
* this is of course coherent with the unlabeled case

So, you can see it as an overloading hack, but you can also build a
metatheory for it. There are even ways to make this typing
principal...

The only weakness is that it is not compatible with unification of
differently ordered function types, but this was removed from ocaml as
non conform to call-by-value semantics.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Claude Marche]

>>>>> "Judicael" == Judicael Courant <Judicael.Courant@lri.fr> writes:

    >> 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.
    >> 
    Judicael> I would vote for this one.

I guess like many people reading this list, I'm very tired with this
thread. I definitely vote for this choice: when a function as been
defined with labels, it has to be called with labelled arguments. Does
it solve all incompatibility problems between classic and label mode ?
If yes, I vote twice!

I see a strong analogy between unlabelled/labelled arguments of
functions and tuples/records types: both are defining product types,
records are usually useful when there are a large numbers of
components, and when you do not want to remember the order of
them. And moreover the { r with ... } construct allows some kind of
default values in records. But could we imagine any useful application
to a record-like type where a record contains both labelled and
non-labelled fields?  I don't think so.

- Claude

-- 
| Claude Marché           | mailto:Claude.Marche@lri.fr |
| LRI - Bât. 490          | http://www.lri.fr/~marche/  |
| Université de Paris-Sud | phoneto: +33 1 69 15 64 85  |
| F-91405 ORSAY Cedex     | faxto: +33 1 69 15 65 86    |
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

Bonjour Claude,

I'm sorry for taking so much bandwidth with this discussion. Yet I do
not see where it can be done, other than the caml-list.
As I put in my disclaimer, if you're not interested, you can just
discard on the title. Not the best solution, but...

> I see a strong analogy between unlabelled/labelled arguments of
> functions and tuples/records types: both are defining product types,
> records are usually useful when there are a large numbers of
> components, and when you do not want to remember the order of
> them. And moreover the { r with ... } construct allows some kind of
> default values in records. But could we imagine any useful application
> to a record-like type where a record contains both labelled and
> non-labelled fields?  I don't think so.

Well, psi-terms in Life (developped at DEC PRL 10 years ago) had such
a feature, and that's where the labels come from. Since they were also
used for data, I would suppose people also used this syntax mixing
labelled and unlabelled fields in records.

A good exemple is a syntax tree: nodes are represented by records,
where one of the fields is a variant giving the type of the node, and
eventually the children. Other fields describe various features of
this node, like position, type, etc...
It seems to me that this main field could very well do without a field
name: in Caml's source it is called desc for description (I think),
but I'm not sure everybody knows what desc stands for...

So, yes, mixing labels and unlabelled fields in a record may be
perfectly meaningful. It is just that most languages do not provide
such a feature. Not that I mean that this feature is really needed:
you have much less record descriptions in a program than function
calls.

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Lionnel Maugis]

I'd like to stress a simple user's viewpoint regarding the 
evolutions of Ocaml, namely to try to Keep It Simple, Sirs. Please.

We've been using ocaml since 1995 since it enables us to 
achieves a fairly good balance of clean and efficient code: 
modular, reusable, type checked. 

(Btw, many thanks to the excellent job done by Xavier and his team !)

With all its new features, we would love to see the learning curve 
and verbosity be kept at a reasonable level. Although Ocaml includes 
advanced features such as lazy structures, classes, labels, stream 
parsers, parameterized modules, to name a few, these are not of 
mandatory use when learning the core language. 

Please to not repell future Ocaml users with mandatory features 
that may be difficult to grasp to newcomers. (We do not all work at
Inria)

As a research language, Ocaml will evolve, but thank you again for
taking 
into account users with various skill levels, and for resisting to the 
need to add things.  

- Lionnel Maugis
Division Routes, Flux et Modélisation
Centre d'Etudes de la Navigation Aérienne
1 rue champagne, Athis-Mons
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[François-René Rideau]

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

>: Jacques Garrigue

> To summarize recent posts by various people, there are two approaches
> for a universal mode:

You left without discussion the approach suggested by Arturo Borquez,
which is quite distinct from that by Chris Hecker:

"An unlabeled argument should be labeled with the first available label
in the declared type of the function being called."

(together with "every function argument declared without label is
given an implicit unique label sui generis"?)

Potential benefits:
* drop-in compatibility with both classic and label mode,
 for those who use consistently use either style.
* allows for continuous change between both styles, depending on what
 one prefers for the function being written.
* works well with fold and higher-order functions and currification.

Potential Problems:
* the order of the labels in the type matters, whereas it didn't,
 which implies compiler changes. I suppose the compiler must currently
 somehow handle order anyway, since even with a possible early canonical
 ordering of labels, you must handle functions that declare a varying
 subset of labels in the global pool.
* it may break either the equivalence between (f x) and (f ~1:x), or the way
 numerical labels do not commute with other labels.
* type declarations that change the order of labels now have some specialness
 in that they modify the meaning of positional parameters. This might be
 something some people would strongly dislike. Or maybe not.
* type inference is made more complex, because of the interaction between
 labelled and unlabelled arguments.

I admit I certainly don't have clear enough an idea of the problems to
judge how doable it is, but if this proposal is doable, it seems to me
that the benefits might be worth it, since it unifies classic and label modes.
In all cases, I'd like to hear about what you think of such proposal,
particularly so if you dismiss it. Let the fact that it was used in some
ancient macroassemblers not make you scorn it.

(I already tried to draw your attention to this approach in the same previous
message when I suggested that a classic mode stdlib could be obtained from
a labelled mode one by writing a camlp4 metaprogram that strips labels and
dumps a wrapper library).

[ François-René DVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
The ancients stole all our ideas from us. -- Mark Twain
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=us-ascii, Size: 1418 bytes --]

From: fare@quatramaran.ens.fr (François-René Rideau)

> You left without discussion the approach suggested by Arturo Borquez,
> which is quite distinct from that by Chris Hecker:
> 
> "An unlabeled argument should be labeled with the first available label
> in the declared type of the function being called."

I might have worded my classification in this (less understandable
way): all proposals have to choose between two types of unification,
strictly matching labels or ignoring them.

You must ignore them to be compatible with classic mode.
You must match them strictly to be compatible with label mode (provide
commutation with any decent semantics).

So this is just impossible to be compatible with both simultaneously.
To some degree you may allow idioms of classic mode in label mode
(like dropping some labels), but not the other way round, and not 100%
compatible.

This is the basic reason I didn't try to answer in detail all
proposals.

The rule you describe here might also be seen as an alternative to
label mode (yet incompatible with classic mode). However it is not
compatible with label mode, semantics are a bit more complex, and
this idea of choosing label by label whether to write or not sounds a
bit too laxist to me (not a good reason, but the other two are).

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Dave Mason]

>>>>> On Thu, 12 Apr 2001 00:34:42 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> said:

> From: fare@quatramaran.ens.fr (François-René Rideau)
>> You left without discussion the approach suggested by Arturo
>> Borquez, which is quite distinct from that by Chris Hecker: "An
>> unlabeled argument should be labeled with the first available label
>> in the declared type of the function being called."

> I might have worded my classification in this (less understandable
> way all proposals have to choose between two types of unification,
> strictly matching labels or ignoring them.

> You must ignore them to be compatible with classic mode.  You must
> match them strictly to be compatible with label mode (provide
> commutation with any decent semantics).

I understand if you only want to implement one of those 2 choices,
after all, it's your time.

However, if it is a question of what should go into my (and many other
people's) favourite language, I think taking those as the only 2
options is rather restrictive, and there are many other possible ways
to do this.

> So this is just impossible to be compatible with both
> simultaneously.  To some degree you may allow idioms of classic mode
> in label mode (like dropping some labels), but not the other way
> round, and not 100% compatible.

I think you should reconsider the suggestion from Borquez (as
encouraged by Rideau), because I think that it would support something
very close to the best of both world (while remaining completely
backward-compatible with `classic' mode).

> This is the basic reason I didn't try to answer in detail all
> proposals.

I must admit I was rather concerned by the response to Remy where you
said you needed all the parameters available at once.  That is not
functional programming as I know and love it!

> The rule you describe here might also be seen as an alternative to
> label mode (yet incompatible with classic mode). However it is not
> compatible with label mode, semantics are a bit more complex, and
> this idea of choosing label by label whether to write or not sounds
> a bit too laxist to me (not a good reason, but the other two are).

It may not be perfectly compatible with `label' mode, but it looks
pretty darned close (although it wouldn't force as many error messages
as perhaps you want).  And it would be completely compatible with
`classic'.  Are those the ``other two'' you refer to?

The important part to me, is that it would allow me to define labels
on *all* my parameters (rather than having to choose which one is
likely to be most useful to leave off), but only use them at
application if I wanted to, and therefore to be able to use labeled
functions with higher-order functions that use multiple parametered
arguments (like fold), without the ugliness of (visible)
eta-expansion.  (If it does eta-expansion behind the scenes if it was
not the last 2 parameters that I left unnamed, so be it.  Just don't
force me to uglify my code!)

There is a syntax that would allow me to control the use of such
arguments rather nicely, I think.  Assume I have:

f: ~a:int -> ~b:int -> ~c:int -> int

I could use fold like:
	fold (f ~b:4 : ~c ~a) [1;2;3] 17
which would, behind the scenes be turned into, essentially:
	fold (function x -> function y -> f y 4 x) [1;2;3] 17
or:
	fold (f ~b:4) [1;2;3] 17
which becomes:
	fold (function x -> function y -> f x 4 y) [1;2;3] 17
or:
	fold (f 4) [1;2;3] 17
which would be the same as:
	fold (f ~a:4) [1;2;3] 17
which can be logically thought of as:
	fold (function x -> function y -> f 4 x y) [1;2;3] 17
but, of course, requires no such expansion.

This may not be as interesting theoretically as the existing label
mode, but it doesn't look that hard to do, and the unification rules
look fairly easy to state.

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

[Caml-list] How do I define prog1?

[Mattias Waldau]

I would like to define a (prog1 a b) which first evaluates a, then b, and
returns the
value of a. (Would be nice if I could have arbitrary number of args.)

I defined it as

let prog1 a b = a

Works well in compiled code, first evaluates a, then b.
However bytecode first evaluates b, then a.

In this cases, call-by-name would be very nice.

One obvious solution is to write

let temp = a in
b;
temp

but that is much too clumsy.

/mattias


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

Re: [Caml-list] How do I define prog1?

[Vitaly Lugovsky]

On Thu, 12 Apr 2001, Mattias Waldau wrote:

> I would like to define a (prog1 a b) which first evaluates a, then b, and
> returns the
> value of a. (Would be nice if I could have arbitrary number of args.)

  What is it for? There must be a better solution!

> I defined it as
>
> let prog1 a b = a
>
> Works well in compiled code, first evaluates a, then b.
> However bytecode first evaluates b, then a.
>
> In this cases, call-by-name would be very nice.

  Evaluation order is not defined. And it must not
be defined for functional languages.

> One obvious solution is to write
>
> let temp = a in
> b;
> temp
>
> but that is much too clumsy.

  What is a type of 'a' and 'b'? And do you really want to evaluate
them before the function call?


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

Re: [Caml-list] How do I define prog1?

[William Chesters]

On Thu, 12 Apr 2001, Mattias Waldau wrote:
 > I would like to define a (prog1 a b) which first evaluates a, then b, and
 > returns the
 > value of a. (Would be nice if I could have arbitrary number of args.)

camlp4 is the natural tool here; I did it once:

  open Pcaml 
  open MLast

  EXTEND
    GLOBAL: expr ctyp patt class_str_item module_expr;

    expr:
      [[ res = expr (* LEVEL "expr1" *); "before"; post = LIST1 expr SEP ";" ->
           <:expr< let __it = $res$ in do $list:post$ return __it >> ]] ;

  END

I think this lets you write e.g.

  let a = ref 1 and b = ref 10 in
  !a + !b before incr a; incr b

    => 11

but I can't see any examples of it in my old code and I don't have
campl4 installed to test it, sorry ...
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: [Caml-list] How do I define prog1?

[Sven LUTHER]

On Thu, Apr 12, 2001 at 02:39:39PM +0200, Mattias Waldau wrote:
> I would like to define a (prog1 a b) which first evaluates a, then b, and
> returns the
> value of a. (Would be nice if I could have arbitrary number of args.)
> 
> I defined it as
> 
> let prog1 a b = a
> 
> Works well in compiled code, first evaluates a, then b.
> However bytecode first evaluates b, then a.
> 
> In this cases, call-by-name would be very nice.
> 
> One obvious solution is to write
> 
> let temp = a in
> b;
> temp

The right solution would be :

  let a = <computation of a> in
  let b = <computation of b> in
  prog a b

to evaluate a before b, and vice versa.

or, if both computation of a and b return unit, you could do :

  a;
  b

Friendly,

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

RE: [Caml-list] How do I define prog1?

[Mattias Waldau]

I got a number of solutions, no good one yet.

(prog1 x1 x2 ...xn)

is a construct in Lisp which evaluates x1..xn and returns
the result of x1. This construct is very useful if
you would like to return the value of x1, but before
returning you would like to logg the result or similar.

It is only useful if the language has mutable data structures
or I/O (:-), which Ocaml has. (And that pragmatic attitude is the
reason I like Ocaml. I want one language to handle every type
of problem reasonable, since today learning the libraries take
so much time.)

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

Re: [Caml-list] How do I define prog1?

[Maxence Guesdon]

Mattias Waldau a écrit :
> 
> I would like to define a (prog1 a b) which first evaluates a, then b, and
> returns the
> value of a. (Would be nice if I could have arbitrary number of args.)
> 
> I defined it as
> 
> let prog1 a b = a
> 
> Works well in compiled code, first evaluates a, then b.
> However bytecode first evaluates b, then a.
> 
> In this cases, call-by-name would be very nice.
> 
> One obvious solution is to write
> 
> let temp = a in
> b;
> temp
> 
> but that is much too clumsy.
> 
> /mattias
> 
> -------------------
If you want prog1 to evaluate a then b, you can do

let prog1 fa fb =
	let a = fa () in
	let _ = fb() in
	a
then call prog1 this way :

prog1 (fun () -> a) (fun () -> b);

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

Re: [Caml-list] How do I define prog1?

[Stefan Monnier]

>>>>> "Mattias" == Mattias Waldau <mattias.waldau@abc.se> writes:
> I would like to define a (prog1 a b) which first evaluates a, then b, and
> returns the value of a.

Since Caml's order of evaluation is unspecified, I don't think there's
any other solution than to use a CamlP4 macro.


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

Re: [Caml-list] How do I define prog1?

[Chris Hecker]

>Since Caml's order of evaluation is unspecified, I don't think there's
>any other solution than to use a CamlP4 macro.

I wonder if you could use the Lazy module to ensure order of evaluation.  You'd have to prefix all the expressions with lazy, so it might be a mess.

Chris

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Brian Rogoff]

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

The situation seems to have calmed down a bit. Or is it just that
there is another more active thread?

Anyway, I think that the conclusion is not very far. At least, we have
collected all known problems about labels, and tried to answer them.

Here is a summary of the plan I tried to draw from many people's
contributions (and my own experience and convictions :-)):

* remove labels from standard libraries
* make label mode the default (and practically unique) mode;
  this preserves compatibility with ocaml 2.x
* slightly extend it to allow non-labelled complete applications of
  functions: this is non-ambiguous, but keep a warning for purists,
  and also because of the slight mismatch between program text and
  untyped semantics
* put some labels in alternative versions of a few libraries
  (List, Array, Unix). Access to these libraries would use already
  existing ways: "open Stdlabels", "module Unix = Lunix"
* also add alternative labelled versions for the few functions with
  more than 4 arguments in the standard library (e.g. String.blit')

I didn't get explicit support for the last addition: allow some
non-labeled applications. Is it useful for some people, or should
we avoid it for the gap in the semantics?

If you're happy with all that, silent consent is enough.
If you think this still misses the point, or something could be
improved, explain yourself, but please do not make proposals: there is
a very high probability that they are going to be flawed at either the
typing or semantics level, and this is very hard to integrate them in
the vision.


Here are some very short answers to many suggestions. Sorry if I
forgot some.

To Claude Marche:
> Could it be interesting that have such an option,
> i.e. allowing at most one non labelled argument ?
I think this is the right way to label most functions. But you cannot
enforce that, because of currying. Also, in some cases the
non-labelled argument is split in two related arguments (something like
base and offset), so you don't need to be too strict on the form. The
idea matters.

To John Skaller:
> Doesn't this simply suggest that the library author should not
> put labels on functions with a small number of obvious arguments?
(S)he is free to do that. But I wouldn't support this idea; this lacks
coherence, and is not really needed. Most higher-order functions do
take functions of only one argument, and in most cases this argument
happens (and not by chance) to be the one left unlabelled in the
function type. The experience is that in most cases eta-expansion is
not even needed. In fact labels may even avoid it, since the
unlabelled argument is not always the last one.

To Brian Rogoff:
> 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?
No hate involved here. This is exactly what the example with subtyping
demonstrated in my previous mail: this cannot be made to work without
badly breaking the semantics. Classic mode and commutation (even with
explicit types) are fundamentally incompatible.
Also, I didn't really see any strong support for labels in classic
mode: labels without commutation are not so much fun.

To Michael Sawka:
> 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.
Thank you for joining the discussion, but this is really what label
mode is about, and it just happens to work, and be relatively simple
(when you don't mix with optional arguments). What you have is a
conservative extension of lamba-calculus (using the default empty
label), where you can also pass arguments on a different label, all
this compiled to plain lambda code for a 0-cost execution model.


Cheers everybody,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Anton Moscal]

On Wed, 11 Apr 2001, Jacques Garrigue wrote:

> The situation seems to have calmed down a bit. Or is it just that
> there is another more active thread?
> 
> Anyway, I think that the conclusion is not very far. At least, we have
> collected all known problems about labels, and tried to answer them.
> 
> Here is a summary of the plan I tried to draw from many people's
> contributions (and my own experience and convictions :-)):
> 
> * remove labels from standard libraries
> * make label mode the default (and practically unique) mode;
>   this preserves compatibility with ocaml 2.x
> * slightly extend it to allow non-labelled complete applications of
>   functions: this is non-ambiguous, but keep a warning for purists,
>   and also because of the slight mismatch between program text and
>   untyped semantics
> * put some labels in alternative versions of a few libraries
>   (List, Array, Unix). Access to these libraries would use already
>   existing ways: "open Stdlabels", "module Unix = Lunix"

If you are going to make new versions of the standard libraries, it's a
good moment for doing some unifications of these libraries:

for example will be good if all "collection" modules (List,Array,
String, Map, Set, Hashtbl) will have similar sets of functions:

for examples - fold's, map's, etc in String,
iteri, mapi, foldi in String, Array, Map, Set etc.

or, for example, types 'a List.t, 'a Array.t for simplifing of usage
Array and List as parameters for functors. etc.


or include functions print:
String.print 
Char.print 
...

instead of print_string etc.

String.compare: string -> string -> int
Char.compare: char -> char -> int
etc.

And many others changes of the same kind.

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Didier Remy]

Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> writes:

Salut Jacques,

I am not sure I understand all your conclusions: 

> Here is a summary of the plan I tried to draw from many people's
> contributions (and my own experience and convictions :-)):
> 
> * remove labels from standard libraries
> * make label mode the default (and practically unique) mode;
>   this preserves compatibility with ocaml 2.x

So far, I understand. 

> * SLIGHTLY extend it to allow non-labelled complete applications of
>   functions: this is non-ambiguous, but keep a warning for PURISTS,
>   and also because of the SLIGHT MISMATCH between PROGRAM TEXT and
>   UNTYPED SEMANTICS

I do not understand much of this sentence. 
Moreover, I am a bit worried by  the use of the words I've emphasized.

> * put some labels in alternative versions of a few libraries
>   (List, Array, Unix). Access to these libraries would use already
>   existing ways: "open Stdlabels", "module Unix = Lunix"
> * also add alternative labelled versions for the few functions with
>   more than 4 arguments in the standard library (e.g. String.blit')

Since these two points are the same, that is, provide alternative labeled
versions of some functions, could they be solved in the same way (introduce
a prime version of module M v.s. introduction primed definitions of
identifier f), so as to avoid dupplicating conventions.

Also, before you chose names for the primed modules, can you find a uniform
convention (c.f. Stdlabels and Lunix that you keep using in examples).  Or,
could these modules have the same name but be defined in a subdirectory of
the stdlib?

Cheers,

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

Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue]

Salut Didier,

> I am not sure I understand all your conclusions: 
> 
> > * SLIGHTLY extend it to allow non-labelled complete applications of
> >   functions: this is non-ambiguous, but keep a warning for PURISTS,
> >   and also because of the SLIGHT MISMATCH between PROGRAM TEXT and
> >   UNTYPED SEMANTICS
> 
> I do not understand much of this sentence. 
> Moreover, I am a bit worried by  the use of the words I've emphasized.

Yes, this is not the kind of language you usually understand. I think I
gave a bit more details on it in the developper's list, but anyway
here are full details for interested people.

The intended "slight" extension:

Suppose I have a function f, of type string -> pos:int -> len:int ->
string. It appears in a program applied on 3 arguments, without any
labels:
        f "Hello" 1 2
The idea is to have the type checker insert the labels rather than
fail with a type error.
To be sure nothing ambiguous is happening, and to avoid "misuses" of
this feature, we have to be a bit strict:
* no argument should be labelled
* the arity of f must be known, and it must exactly match the number
  of arguments
In particular functions whose return type is a type variable are not
eligible for that, since their arity is unknown.

With all these conditions, it is clear that no ambiguity will happen:
type checking was going to fail otherwise, and there is only one way
to add labels in this application.
If you care about stronger properties than that, in the current
version type checking with labels is not complete, but it produces a
unique type: when type checking succeeds, the type it finds does not
depend on the inference algorithm, but whether a type will be found or
not depends on it. Basically this property is not changed: either we
knew the complete type for f at the application point, and could add the
right labels, or we didn't know the type and it will fail either
immediately or later.
By the way, we were doing something pretty similar in our paper on
first class polymorphism.

The problem I describe at the semantics level is related to this
notion of adding labels. Without optional arguments, the reduction in
label mode can be described by this single rule:
 (fun ~ln:x -> e) ~l1:v1 ... ~ln:vn ---> e[vn/x] ~l1:v1 ... ~ln-1:vn-1
No label is just the empty label, behaving exactly like other labels.

If we try to apply a labelled function to unlabelled arguments (with
empty labels), reduction will be stuck. So this idea of "adding
labels" during type checking, which results in this "slight" gap
between the program and its untyped semantics: there is no ambiguity,
but the program you reduce is not exactly the one you wrote (which
would have been stuck anyway). So the warning is both for semantics
purists, who want to be sure they can apply semantic rules directly on
their source code, and label purists, who do not want to omit labels
anyway.

I suppose there are other ways to handle this, by extending a bit the
semantics, but you would still need some kind of non-syntactic
information, like the arity of f.

> > * put some labels in alternative versions of a few libraries
> >   (List, Array, Unix). Access to these libraries would use already
> >   existing ways: "open Stdlabels", "module Unix = Lunix"
> > * also add alternative labelled versions for the few functions with
> >   more than 4 arguments in the standard library (e.g. String.blit')
> 
> Since these two points are the same, that is, provide alternative labeled
> versions of some functions, could they be solved in the same way (introduce
> a prime version of module M v.s. introduction primed definitions of
> identifier f), so as to avoid dupplicating conventions.
> 
> Also, before you chose names for the primed modules, can you find a uniform
> convention (c.f. Stdlabels and Lunix that you keep using in examples).  Or,
> could these modules have the same name but be defined in a subdirectory of
> the stdlib?

I do not expect many of them, and I'm not even sure users will want to
use labels everywhere simultaneously: labellings in List and Unix are
rather different in nature. So they could happily stay in the main
directory. Also having primes in module names may be problematic,
if they are to be compilation units: any idea on how various operation
systems handle primes in file names?

I must admit I didn't seriously consider the problem of naming. We
could probably find a solution among developpers. And a prerequisite
is of course that this proposal (or a variant of it) gets accepted,
which is not clear yet.

Best regards,

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