[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 1998-12-11 (13:58) |
From: | John Harrison <John.Harrison@c...> |
Subject: | Re: Functional composition operator? |
| > | 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.