From: Pierre Weis <Pierre.Weis@inria.fr>
To: John.Harrison@cl.cam.ac.uk (John Harrison)
Cc: caml-list@inria.fr
Subject: Re: Functional composition operator?
Date: Wed, 9 Dec 1998 11:58:26 +0100 (MET) [thread overview]
Message-ID: <199812091058.LAA12029@pauillac.inria.fr> (raw)
In-Reply-To: <E0znV41-00070g-00@heaton.cl.cam.ac.uk> from "John Harrison" at Dec 8, 98 09:52:54 pm
> | In fact we discourage the usage of functional composition as a general
> | programming tool
>
> A very bad idea, in my opinion.
I'm not sure I got the point here. Why is it a very bad idea ?
Do you consider FP style programming the right functional programming style ?
> | -- it only save a few characters in programs
> | (Compare
> | let h = f o g
> | with
> | let h x = f (g x);;)
> | -- it breaks the polymorphism
> | (if defined as
> | let h = f o g
> | h is not generalized, since its definition is a function
> | application, whereas inline expansion of functional composition
> | let h x = f (g x)
> | being the definition of a function is properly generalized.)
>
> These alternatives are not semantically equivalent. If f and g are
> complicated expressions that can be further evaluated, it is often
> highly undesirable to perform the evaluation every time h is called,
> which is what "let h x = f(g x)" entails.
Right, if you consider that efficiency has something to do with the
semantics, which is not the classical acceptation of this term. To be
precise, if f and g are side-effect free, these alternatives are
indeed ``semantically equivalent'' in the classical view of semantics
(same answer). Anyway, I was implicitely assuming that f and g were
functions, and h was invariant by eta-expansion. In my mind, if h is
not invariant by eta-expansion, the program is hard to read and hard
to understand. Anyway, if f and g are not mere functions but ``very
complicated expressions'' the program is likely to be clearer if you
bind these expressions with a let and give them a name, instead of
composing these complex expressions inline. Let alone the case when
these expressions involve side-effects: then, if you still insist at
composing them on the fly, you get an order of evaluation dependant
program and this must be carefully avoided. In conclusion, if you
freely mix inline composition, side-effects and partial evaluation you
get very complex programs, hard to understand and hard to
maintain. That's my experience in maintaining and developping a
compiler written with that style, using a free mixing of composition,
partial evaluation, and continuations.
Anyway, if you can manage the additional complexity, there is no
problem at using a highly ``composing'' style in Caml. However, in my
mind, it is not a good idea to promote this style, especially for the
working programmer.
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/
next prev parent reply other threads:[~1998-12-09 11:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-08 5:23 John Whitley
1998-12-08 17:02 ` Pierre Weis
1998-12-08 21:52 ` John Harrison
1998-12-09 10:58 ` Pierre Weis [this message]
1998-12-09 17:17 ` John Harrison
1998-12-11 13:57 ` Pierre Weis
1998-12-08 18:08 Andrew Kay
1998-12-08 20:32 ` John Prevost
1998-12-09 16:17 ` Anton Moscal
1998-12-08 19:51 Don Syme
1998-12-08 20:09 Don Syme
1998-12-09 12:00 Don Syme
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=199812091058.LAA12029@pauillac.inria.fr \
--to=pierre.weis@inria.fr \
--cc=John.Harrison@cl.cam.ac.uk \
--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;
as well as URLs for NNTP newsgroup(s).