From: Wolfram Kahl <kahl@heraklit.informatik.unibw-muenchen.de>
To: caml-list@inria.fr
Subject: Re: Syntax for label, NEW PROPOSAL
Date: Fri, 17 Mar 2000 18:33:07 +0100 [thread overview]
Message-ID: <200003171733.SAA19068@aphrodite.Informatik.UniBw-Muenchen.DE> (raw)
In-Reply-To: <20000317161335.33553@pauillac.inria.fr> (message from Pierre Weis on Fri, 17 Mar 2000 16:13:35 +0100)
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
next prev parent reply other threads:[~2000-03-17 18:50 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
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 [this message]
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=200003171733.SAA19068@aphrodite.Informatik.UniBw-Muenchen.DE \
--to=kahl@heraklit.informatik.unibw-muenchen.de \
--cc=caml-list@inria.fr \
/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