Re: Functional composition operator?

[John Harrison <John.Harrison@cl.cam.ac.uk>]

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

The whole point of a higher order functional language is to treat functions 
(more) on a par with other values. Therefore it seems wrongheaded to seek
to discourage programmers from using one of the most basic operations on 
functions.

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

Well, even for side-effect-free expressions, the difference in efficiency
could be decisive in practical terms. And if you do use side effects it
matters even more. 

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

It depends on what you mean by order of evaluation. If you mean whether
"f" or "x" gets evaluated first in "f(x)", then I agree. But the fact
that the body of a function is not evaluated till it gets its argument
is basic to an ML-like functional language, and a dependence on this is not
at all something to be avoided. On the contrary, a serious use of side
effects requires an understanding of just when things get evaluated, which
is a good reason why the combination of side effects and a lazy language is
unusual.

Here is a simple example (from theorem proving, funnily enough) where
composition seems to me natural and where partial evaluation is important.

  let rule = rewrite[theorems2] o rewrite[theorems1];;

Typically, the partial evaluation of "rewrite[theorems?]" is critical 
because it builds a data structure from the theorems before starting 
the rewrite.

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

I wasn't necessarily proposing such a ragbag. But as Don Syme has pointed
out, there are many perfectly natural and disciplined ways of using side
effects within globally functional code.

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

I don't really know what you mean by "working programmer". If you mean
"programmer who writes the same kinds of programs as I do", then it's
a poor foundation for a panoptic view of the field. I'm happy for
people to avoid composition if that's what they want. However I don't like
the idea of discouraging new programmers from using it even when it
could be very helpful and natural.

John.