Re: Syntax for label, NEW PROPOSAL

From: Jacques Garrigue (garrigue@kurims.kyoto-u.ac.jp)
Date: Fri Mar 17 2000 - 15:05:43 MET

  • Next message: Pierre Weis: "Re: Syntax for label, NEW PROPOSAL"

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



    This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 16:33:20 MET