From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA21400 for caml-redistribution; Fri, 11 Dec 1998 14:58:07 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA19393 for ; Wed, 9 Dec 1998 18:17:38 +0100 (MET) Received: from heaton.cl.cam.ac.uk (heaton.cl.cam.ac.uk [128.232.32.11]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id SAA11449; Wed, 9 Dec 1998 18:17:36 +0100 (MET) Received: from albatross.cl.cam.ac.uk (cl.cam.ac.uk) [128.232.0.96] by heaton.cl.cam.ac.uk with esmtp (Exim 1.82 #1) id 0znnEp-00050H-00; Wed, 9 Dec 1998 17:17:23 +0000 X-uri: To: Pierre Weis cc: Don Syme , John.Harrison@cl.cam.ac.uk (John Harrison), caml-list@inria.fr Subject: Re: Functional composition operator? In-reply-to: Your message of "Wed, 09 Dec 1998 11:58:26 +0100." <199812091058.LAA12029@pauillac.inria.fr> Date: Wed, 09 Dec 1998 17:17:22 +0000 From: John Harrison Message-Id: Sender: weis | > | 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.