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

[Dave Mason <dmason@sarg.Ryerson.CA>]

>>>>> 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