[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

[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

[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

[Judicael Courant]

Hi,

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

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

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

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

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

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

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

Sincerly yours,

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

RE: [Caml-list] Future of labels

[Mattias Waldau]

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

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

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

As I see it

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

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

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

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

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

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

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

/mattias

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

[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

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

[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

[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