RE: [Caml-list] Future of labels

["Mattias Waldau" <mattias.waldau@tacton.se>]

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