caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <Pierre.Weis@inria.fr>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
Date: Fri, 17 Mar 2000 17:08:57 +0100	[thread overview]
Message-ID: <20000317170857.64628@pauillac.inria.fr> (raw)
In-Reply-To: <20000317230543D.garrigue@kurims.kyoto-u.ac.jp>; from Jacques Garrigue on Fri, Mar 17, 2000 at 11:05:43PM +0900

> There may indeed be good reasons for let-binding.
> However, if you look at the sources of ocaml, you will see that in
> many, many places such functions are defined inline without
> let-binding. I see two reasons for that:
> * you often don't want to think of a name for such a function
>   (most of them are just 2 or 3 line long)

Is this argument relevant to the problem at hand ? You were speaking
of the advantage of using a label fun: for applying map to a ``long
multi line function definition'':

>               fun:(fun long multi line function  definition here)

If the function is ``long'' and multi line, I definitively prefer a let
binding. If it is not ``long'' I prefer no label and a short and
elegant (fun x -> ...).

> * it forces you to move the code around in a way that is not
>   necessarily very natural. It's a bit like RPN: first define a
>   function, then apply a functional to it.
>   (We could of course ressucite the where clause :-)

Yes that's fundamentally the way it goes in Caml: define first
something then use it (static binding). I'm sorry, we removed the
where construct a long time ago exactly with this argument.

As you say below ``More generally, my experience is that''

* once anonymous functions are named, the code is clearer
* when anonymous functions are ``long multi line'' the code is obscure.

> More generally, my experience is that more freedom in the way to
> layout them increases the use of functionals. After all there are many
> ways to see the same function, different logical understanding of its
> meaning. And the fact you can use all these ways with the same function
> avoids confusion.
> Why should we decide that one way is right, and others are wrong?

You already answered to this question in your paragraph: I would answer
in the first place with the very reasons you are advocating to ask why
we should decide; you wrote ``my experience'', ``logical
understanding'', ``avoids confusion''.

So, we should decide that one way is right based on experience, theorems,
confusion avoidance, logical understanding, ....

Amicalement,

-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis



  reply	other threads:[~2000-03-17 16:21 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-14 16:53 Syntax for label Don Syme
2000-03-14 18:05 ` Pierre Weis
2000-03-15  3:15 ` Syntax for label, NEW PROPOSAL Jacques Garrigue
2000-03-15  6:58   ` Christophe Raffalli
2000-03-15 21:54     ` Julian Assange
2000-03-15 11:56   ` Wolfram Kahl
2000-03-15 13:58   ` Pierre Weis
2000-03-15 15:26     ` Sven LUTHER
2000-03-17  7:44       ` Pierre Weis
2000-03-15 17:04     ` John Prevost
2000-03-17 10:11       ` Jacques Garrigue
2000-03-15 17:06     ` Markus Mottl
2000-03-15 19:11     ` Remi VANICAT
2000-03-17  8:30       ` Pierre Weis
2000-03-17 14:05         ` Jacques Garrigue
2000-03-17 16:08           ` Pierre Weis [this message]
2000-03-18 10:32           ` Syntax for label, NEW SOLUTION Christophe Raffalli
2000-03-19  2:29             ` Jacques Garrigue
2000-03-20 18:25               ` Christophe Raffalli
2000-03-22  8:37                 ` Claudio Sacerdoti Coen
2000-03-21 23:29               ` John Max Skaller
2000-03-29  8:42               ` Semantic of label: The best (only ?) solution to merge both mode Christophe Raffalli
2000-03-29  9:53                 ` Christophe Raffalli
2000-03-30  9:49                   ` John Max Skaller
2000-03-30  9:39                 ` John Max Skaller
2000-03-31  4:34                   ` Jacques Garrigue
2000-04-01  1:53                     ` John Max Skaller
2000-04-02 19:24                     ` Christophe Raffalli
2000-04-04  5:50                       ` Jacques Garrigue
2000-04-03  7:57                     ` backward compatibility Christophe Raffalli
2000-03-15 21:30     ` Syntax for label, NEW PROPOSAL John Max Skaller
2000-03-16  2:55     ` Jacques Garrigue
2000-03-17 15:13       ` Pierre Weis
2000-03-17 17:33         ` Wolfram Kahl
2000-03-18 11:59         ` Jacques Garrigue
2000-03-21 16:51       ` Pascal Brisset
2000-03-23 11:14         ` Nicolas barnier
2000-03-24  9:54           ` labels & ocaml 3 & co David Mentré
2000-03-24 12:19             ` David Mentré
2000-03-21 22:22       ` Unsigned integers? John Max Skaller
2000-03-22 16:22         ` Sven LUTHER
2000-03-23  2:08           ` Max Skaller
2000-03-23  7:50             ` Sven LUTHER
2000-03-24  2:50             ` Jacques Garrigue
2000-03-24 15:59               ` Xavier Leroy
2000-03-25  4:03               ` John Max Skaller
2000-03-24 14:50             ` Xavier Leroy
2000-03-22 17:05         ` Jean-Christophe Filliatre
2000-03-22 19:10           ` Markus Mottl
2000-03-23  2:41           ` Max Skaller
2000-03-22 19:47         ` Xavier Leroy
2000-03-23 12:55           ` John Max Skaller
2000-03-16  8:50     ` Syntax for label, NEW PROPOSAL Pascal Brisset
2000-03-17 11:15       ` Sven LUTHER
2000-03-18  0:04     ` Syntax for label, ANOTHER " Steven Thomson
2000-03-15 20:39   ` Syntax for label (and more) Xavier Leroy
2000-03-17 10:03     ` Christian RINDERKNECHT
2000-03-17 17:19       ` Christophe Raffalli
2000-03-21  1:29     ` Markus Mottl
2000-03-15 20:40 Syntax for label, NEW PROPOSAL Don Syme
2000-03-17  9:48 ` Jacques Garrigue
2000-03-17 17:34   ` Dave Mason
2000-03-18  0:26     ` Jacques Garrigue
2000-03-23 13:07       ` Sven LUTHER
2000-03-17 17:03 Don Syme
2000-03-17 19:24 ` John Prevost
2000-03-17 21:33 Damien Doligez
2000-03-18 21:07 ` Frank Atanassow
2000-03-18 22:40 ` John Prevost

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=20000317170857.64628@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --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).