From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA17270 for caml-redistribution@pauillac.inria.fr; Fri, 17 Mar 2000 16:31:17 +0100 (MET)
Resent-Message-Id: <200003171531.QAA17270@pauillac.inria.fr>
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA12144 for <weis@pauillac.inria.fr>; Fri, 17 Mar 2000 15:03:08 +0100 (MET)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA12561;
	Fri, 17 Mar 2000 15:03:06 +0100 (MET)
Received: from tet.kurims.kyoto-u.ac.jp (isdnppp2.kurims.kyoto-u.ac.jp [130.54.16.103])
	by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id XAA29237;
	Fri, 17 Mar 2000 23:03:03 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by tet.kurims.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id XAA28335;
	Fri, 17 Mar 2000 23:05:43 +0900 (JST)
	(envelope-from garrigue@kurims.kyoto-u.ac.jp)
To: Pierre.Weis@inria.fr
Cc: remi.vanicat@labri.u-bordeaux.fr, caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
In-Reply-To: Your message of "Fri, 17 Mar 2000 09:30:58 +0100"
	<20000317093058.30145@pauillac.inria.fr>
References: <20000317093058.30145@pauillac.inria.fr>
X-Mailer: Mew version 1.93 on Emacs 20.4 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000317230543D.garrigue@kurims.kyoto-u.ac.jp>
Date: Fri, 17 Mar 2000 23:05:43 +0900
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
X-Dispatcher: imput version 980905(IM100)
Resent-From: weis@pauillac.inria.fr
Resent-Date: Fri, 17 Mar 2000 16:31:17 +0100
Resent-To: caml-redistribution@pauillac.inria.fr

> > also i do want the fun: label (you may change the name, but a label
> > here is useful) to be able to write 
> > 
> > let sum l = List.fold_right acc:0
> >               fun:(fun long multi line function  definition here)
> > 
> > but i agreed that the acc label (in fun x acc:y -> x + y) is a pain,
> > because he forbid the use of usual function here 
> 
> I don't think this ``long multi line function  definition here'' is a
> really good argument. Several years ago, I thought the same, so that I
> defined *_on version of list functionals with list in the first place
> instead of at the end; for instance, I could write:
> 
> map_on l (fun x -> long multi line function)
> 
> Now I'm sure this is not the right solution to a real problem: the
> elegant way to deal with that is to name the function using a let.
> 
> let eta_expand x =
>  ... in
> 
> map eta_expand l.
> 
> Several arguments are in favor of a let binding:
> 
> - we still have only one functional and one way to call it
> - we have no unreadable long inline function definitions
> - the name we give to the function helps to understand its semantics
> - we can use the same construction in case of more complex function
> even in case of recursive function, where the fun x -> construct is
> hopeless (to solve this problem a ``fun rec'' construct have been
> proposed once, but the let rec way is much simpler, regular and
> elegant!)
> - the let way is a general solution to the general problem of long
> multi-line expressions in every construct of the language, including
> arithmetic operations.

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)
* 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 :-)

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?

Jacques