Re: Syntax for label, NEW PROPOSAL

From: Wolfram Kahl (kahl@heraklit.informatik.unibw-muenchen.de)
Date: Fri Mar 17 2000 - 18:33:07 MET

  • Next message: Dave Mason: "Re: Syntax for label, NEW PROPOSAL"

    As a long time user of OLabl, I was very happy when the ``great merger''
    was announced. I was also very happy that there were quite a few
    very positive reactions on this list, and that there was the understanding
    that the merger should serve both those who wanted to stay in their old
    worlds, be it the world with or the world without labels
    (by making libraries written in the other world accessible to them),
    and those who wanted to do some border-crossing.

    In the last few days, however,
    the tone seems to have changed considerably ---
    before a religious war breaks out,
    I would recommend reading ``Nathan der Weise'' by Lessing ;-)

    More to the point:

    Pierre Weis <Pierre.Weis@inria.fr> writes:
    > I'm afraid I don't agree with you: commuting between arguments is not
    > worth the extra burden of having labels, I'm not sure it is even
    > desirable. I think that when arguments of a function are not always
    > passed in the same order the readibility of the code is jeopardized.

    To me, for some functions the arguments are in the wrong order
    whichever order you put them.
    Even for some functions in the standard library.

    So when writing applications of these functions,
    I have to look them up anyway --- and for me it is faster
    to do this via LablBrowser/CamlBrowser than via the local
    installation of the HTML version of the manual.

    When reading the code, however, with labels
    I do not have to look up the function at all!

    I find code with heavy use of functions with more than three arguments
    hard to read without labels --- no matter whether ML or Haskell.
    I find myself routinely writing functions
    with around ten non-optional arguments.
    And I am glad that I can add another five optional arguments,
    should the need arise,
    to spare me the copy-and-paste of the function definition for a new variant.
    I find labels indispensable for this.
    I often do copy-and-paste for the labelled applications ;-),
    and labels help to find the place to be changed.
    But the real pay-off comes at the time of reading the code
    (which I do, sometimes :-),
    when I can read it without having to look up the definition.

    Of course, there are other programming styles, too,
    and very algebraic combinator-style programming
    will profit much less from labels, and look nicer in classic style.

    I love higher order functions, too, so initially the requirement
    to do long eta normal forms seemed to be a drawback to me
    just the same way as to some people on the list.

    However, nowadays I find myself doing ``fold_right (+)'' much less
    than ``fold_right myfunction'', where ``myfunction'' often is
    a partial application of a more-argument function
    that has been let-defined a few lines above ---
    this application can still be multi-line,
    but since the more-argument function has been let-defined for the purpose
    of having its instances used in fold_right,
    I find that adding this one extra label in the let-definition
    does no harm at all, on the contrary,
    it adds to the readability of the definition of the more-argument function.

    So for me, labels have proved to be the right thing for what I do
    with OCaml/OLabl --- but then, I do not claim to be a typical user:
    When doing combinator-style programming, I prefer Haskell,
    and, half joking, I consider OCaml/OLabl an imperative programming language
    just by virtue of its not being purely functional
    (I do not use other imperative programming languages,
     (except shells), and I also recommend my students not
     to use other imperative programming languages ---
     some even understand and follow :-).

    Maybe the question to be discussed
    is which kind of mixtures between the two styles
    should be enabled by the compiler.
    For my perception of OCaml-3.0, however,
    I think it is sufficient if it just puts the two worlds
    of no-label-users and label-users
    on a common technical basis,
    without forcing anybody to really change their style
    (which is, as I perceive and understand it,
     the design philosophy followed so far).

    Best regards,

    Wolfram



    This archive was generated by hypermail 2b29 : Fri Mar 17 2000 - 19:51:51 MET