[Caml-list] Future of labels

[Caml-list] Future of labels

[Jacques Garrigue]

Hello everybody,

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

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

Personally I see two possible directions.

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

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

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

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

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

Cheers,

Jacques Garrigue

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

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

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

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

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

RE: [Caml-list] Future of labels

[Jacques Garrigue]

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

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

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

Commuting for non-optional arguments is another problem.

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

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

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

Does this answer you question ?

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

RE: [Caml-list] Future of labels

[Mattias Waldau]

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

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

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

As I see it

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

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

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

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

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

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

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

/mattias

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


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

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

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

Commuting for non-optional arguments is another problem.

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

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

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

Does this answer you question ?

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

RE: [Caml-list] Future of labels

[Mattias Waldau]

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

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

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

As I see it

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

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

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

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

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

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

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

/mattias

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

Re: [Caml-list] Future of labels

[Chris Hecker]

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

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

Chris

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

Re: [Caml-list] Future of labels

[Markus Mottl]

Hello,

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

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

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

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

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

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

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

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

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

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

Regards,
Markus Mottl

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

Re: [Caml-list] Future of labels

[John Max Skaller]

Markus Mottl wrote:

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

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

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

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

	fun x y -> pi ()

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

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

	fun x y -> ...

becomes

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

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

	f x y

we add integer labels to the unlabelled arguments by position:

	f ~0:x ~1:y

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

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

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

[Caml-list] Indexed and optional arguments (was Future of labels)

[Jacques Garrigue]

[ This is only remotely related to the original subject ]

From: John Max Skaller <skaller@ozemail.com.au>

> 	Ideally, we'd like to have label mode, with some support
> for positional arguments by syntactic sugar (so there is only one
> mode and one explanation of the fundamental paradigm). For example:
> 
> 	fun x y -> ...
> 
> becomes
> 
> 	fun ~0:x ~1:y -> ...
> 
> that is, we use integers as the labels for a positional definition,
> and in the call:
> 
> 	f x y
> 
> we add integer labels to the unlabelled arguments by position:
> 
> 	f ~0:x ~1:y
> 
> In this way, we have only strict commuting label mode, but we can still
> use positional notation via sugar.

This is already the case :-)
Label-selective lambda-calculus, on which the label mode is based,
includes both numerically indexed and labelled arguments, and position
arguments follow exactly the sugar you explained above.
"The typed polymorphic label-selective lambda-calculus" is a good
reference. See http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/.

More precisely, (f x y) is equivalent to (f ~1:x ~2:y) (I prefer
starting from 1), which is itself equivalent to both ((f ~1:x) ~1:y)
and ((f ~2:y) ~1:x). That's all the point of selective
lambda-calculus: merging out-of-order partial application and
currying.

Indexes are not in OCaml, because the rules to compute them in
presence of commutation seemed too complex for daily use, but the
theory is still integrated: you can view no label as a special label
"1", and use the same rules for all arguments.

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

The rule in OCaml tries to be simple: applying a function containing
optional parameters to a non-labeled argument which is abstracted
_after_ optional ones causes them to be discarded.

If you have a function
  f : ?a:int -> int -> ?b:int -> int -> int
Then
  (f 0) : ?b:int -> int -> int
and
  (f 0 0) : int
So you see that you can discard optional arguments without giving all
non-optional arguments.
I used types in the above explanation, but you can also explain in a
completely untyped way. See "Labeled and optional arguments for
Objective Caml" in my publications.

Cheers,

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

[Caml-list] Re: Indexed and optional arguments (was Future of labels)

[John Max Skaller]

Jacques Garrigue wrote:

> > In this way, we have only strict commuting label mode, but we can still
> > use positional notation via sugar.
 
> This is already the case :-)

	If that is so, then provided libraries contain no labels,
all existing 'classic' Ocaml code will continue to work in
strict commuting label mode.

	In particular, no 'classic' ocaml user will notice
any difference: only 'classic mode' users who played with
some labels (and probably expected to get burned by 
further changes anyhow). Is that right?

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

Re: [Caml-list] Future of labels

[Markus Mottl]

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

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

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

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

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

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

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

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

This looks messy to me.

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

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

Regards,
Markus Mottl

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

Re: [Caml-list] Future of labels

[John Max Skaller]

Markus Mottl wrote:

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

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

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

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

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

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


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

	let f x y = y in
	fold_left f x l

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

	On the other hand:

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

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

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

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

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

Re: [Caml-list] Future of labels

[Markus Mottl]

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

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

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

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

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

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

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

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

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

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

Regards,
Markus Mottl

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

Re: [Caml-list] Future of labels

[Judicael Courant]

Hi,

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

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

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

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

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

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

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

Sincerly yours,

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

[Caml-list] Implicit parameters (was Future of labels)

[Jacques Garrigue]

> [The following is probably off-topic and probably needs quite a lot of
> work to be put in O'Caml but we can expect miracles from the Caml team,
> can not we?]
> A wish about optionnal arguments: I would use them a lot if they where a
> bit more... optionnal, in the style of implicit parameters of
> http://citeseer.nj.nec.com/lewis00implicit.html.
> 
> This would be really helpful when defining printers (where you have to
> carry everywhere the channel on which you are printing), when you are
> defining a type-checker (you must carry the current environment that is
> unchanged in all your rules but the one about lambda-abstraction, ...).

For those who didn't read the paper, this is really more about dynamic
scoping than default parameters.
In particular, their framework does not subsume ours (defaults cannot
be defined individually for each function).
(*They refer to label-selective lambda calculus (the foundation for
labeled argument in Caml), with the interesting comment that "it is
unclear whether such a change would integrate well in existing
functional languages"*)

Their system in itself uses the same mechanism as type classes, of
putting information into a constraint environment. I do not see how
one could do that in ML.

You can easily do dynamic scoping in ML (contrary to Haskell), by
using references. The only pitfall is that the produced code is not
reentrant.

     let set_dynamic r v f x =
       let old = !r in
       try r := v; let y = f x in r := old; y
       with exn -> r := old; raise exn

     let r = ref default
     let f () = !r
     let g x = set_dynamic r x f ()

A variant of this can be applied to printers, since by default they
call Format.std_formatter.

I suppose you might add some better syntax with camlp4.
Can this be made to work in a threaded program ?
This is a very interesting question...

For the specific case of a type checker, optional arguments can help:

let rec type_expr env expr =
  let type_expr ?(env=env) = type_expr env in
  match expr with ...
  | Lambda (var, body) -> ... type_expr ~env:(Env.add var ty env) body...

If your problem is that you have many such arguments to pass around,
then commuting labeled argument can also be helpful: you just have to
copy/paste the argument list at each function call, without caring
about their order.

I hope some of these methods can fit your needs.

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

Re: [Caml-list] Implicit parameters (was Future of labels)

[Markus Mottl]

On Fri, 30 Mar 2001, Jacques Garrigue wrote:
> You can easily do dynamic scoping in ML (contrary to Haskell), by
> using references. The only pitfall is that the produced code is not
> reentrant.

Another solution to this problem is to use a state monad that passes
around the parameter implicitly. This would also keep the code purely
functional (= reentrant).

The only problem here is that using monads in their general form with
OCaml is usually more cumbersome than with Haskell due to the lack
of overloading. It's also a quite bit slower than passing around the
parameter explicitly.

For those who want to see an example of the use of state monads and to
compare with a solution that passes around the state parameter explicitly,
you can take a look at the following:

  http://www.oefai.at/~markus/ocaml_sources/IMP-1.0-3.tar.gz

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

[Manuel Fahndrich]

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

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

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

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

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

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

RE: [Caml-list] Future of labels

[Jacques Garrigue]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nice, a real classic mode user!

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

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

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

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

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

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

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

Cheers,

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

Re: [Caml-list] Future of labels

[Markus Mottl]

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

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

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

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

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

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

Regards,
Markus Mottl

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

Re: [Caml-list] Future of labels

[kahl]

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

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

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

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

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

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

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

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


Cheers,

Wolfram Kahl







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

Re: [Caml-list] Future of labels

[Jacques Garrigue]

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

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

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

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

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

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

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

Cheers,

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

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

Hi Jacques,

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

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

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

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

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

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

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

        Benjamin


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

Re: [Caml-list] Future of labels

[Judicael Courant]

Jacques Garrigue a écrit :

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

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

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

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

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

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

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

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

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

Re: [Caml-list] Future of labels

[Jacques Garrigue]

Hello Judicael,

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

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

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

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

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

Jacques

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

Re: [Caml-list] Future of labels

[Francois Pottier]

Jacques,

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

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

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

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

Re: [Caml-list] Future of labels

[Benjamin C. Pierce]

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

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

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

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

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

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

Re: [Caml-list] Future of labels

[Jean-Marc Alliot]

"Benjamin C. Pierce" wrote:

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

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

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

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


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



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

RE: [Caml-list] Future of labels

[Arturo Borquez]

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

Best Regards
Arturo Borquez


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

RE: [Caml-list] Future of labels

[Jacques Garrigue]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,

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

Re: [Caml-list] Future of labels

[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

[G Michael Sawka]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unallowed applications:

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

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

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


                      -mike.


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


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