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 MAA30156 for caml-redistribution; Wed, 9 Dec 1998 12:00:00 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA08402 for ; Wed, 9 Dec 1998 11:58:31 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA26383; Wed, 9 Dec 1998 11:58:27 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA12029; Wed, 9 Dec 1998 11:58:26 +0100 (MET) From: Pierre Weis Message-Id: <199812091058.LAA12029@pauillac.inria.fr> Subject: Re: Functional composition operator? To: John.Harrison@cl.cam.ac.uk (John Harrison) Date: Wed, 9 Dec 1998 11:58:26 +0100 (MET) Cc: caml-list@inria.fr In-Reply-To: from "John Harrison" at Dec 8, 98 09:52:54 pm X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 ? > | -- 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/