caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Markus Mottl <mottl@miss.wu-wien.ac.at>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Future of labels
Date: Thu, 29 Mar 2001 11:46:40 +0200	[thread overview]
Message-ID: <20010329114640.A18984@miss.wu-wien.ac.at> (raw)
In-Reply-To: <20010329094438J.garrigue@kurims.kyoto-u.ac.jp>; from garrigue@kurims.kyoto-u.ac.jp on Thu, Mar 29, 2001 at 09:44:38 +0900

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


  parent reply	other threads:[~2001-03-29  9:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-29  0:44 Jacques Garrigue
     [not found] ` <AAEBJHFJOIPMMIILCEPBEEFHCHAA.mattias.waldau@abc.se>
2001-03-29  6:43   ` Jacques Garrigue
2001-03-29 11:44     ` Mattias Waldau
2001-03-29 17:52     ` Mattias Waldau
2001-03-29  8:22 ` Chris Hecker
2001-03-29  9:46 ` Markus Mottl [this message]
2001-04-09  1:28   ` John Max Skaller
2001-04-09  8:33     ` [Caml-list] Indexed and optional arguments (was Future of labels) Jacques Garrigue
2001-04-10 18:23       ` [Caml-list] " John Max Skaller
2001-04-09  8:45     ` [Caml-list] Future of labels Markus Mottl
2001-04-10 18:42       ` John Max Skaller
2001-04-10 22:01         ` Markus Mottl
2001-03-29 12:53 ` Judicael Courant
2001-03-30  3:42   ` [Caml-list] Implicit parameters (was Future of labels) Jacques Garrigue
2001-03-30  7:55     ` Markus Mottl
2001-03-29 19:56 [Caml-list] Future of labels Manuel Fahndrich
2001-03-30  3:01 ` Jacques Garrigue
2001-03-30  8:23   ` Markus Mottl
2001-03-30  9:45   ` kahl
2001-03-30 10:43     ` Jacques Garrigue
2001-03-30 12:32       ` Benjamin C. Pierce
2001-03-30 10:39   ` Judicael Courant
2001-03-30 10:54     ` Jacques Garrigue
2001-03-30 11:22   ` Francois Pottier
2001-03-30 12:41     ` Benjamin C. Pierce
2001-03-30 14:16       ` Jean-Marc Alliot
2001-03-29 23:47 Arturo Borquez
     [not found] <200103300810.AAA05312@mrs.mrs.med.ge.com>
2001-03-30 10:31 ` Jacques Garrigue
2001-03-31  3:40 Yaron M. Minsky
2001-04-11  3:35 G Michael Sawka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010329114640.A18984@miss.wu-wien.ac.at \
    --to=mottl@miss.wu-wien.ac.at \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-u.ac.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).