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 PAA20243 for caml-redistribution; Wed, 9 Dec 1998 15:40:41 +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 NAA29010 for ; Wed, 9 Dec 1998 13:00:46 +0100 (MET) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id NAA05809; Wed, 9 Dec 1998 13:00:44 +0100 (MET) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Wed, 9 Dec 1998 04:00:44 -0800 Message-ID: <39ADCF833E74D111A2D700805F1951EF0B2EF6B8@RED-MSG-06> From: Don Syme To: "'Pierre Weis'" , John.Harrison@cl.cam.ac.uk Cc: caml-list@inria.fr Subject: RE: Functional composition operator? Date: Wed, 9 Dec 1998 04:00:39 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: weis > 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 think it simply depends on what you're doing: highly symbolic work like theorem proving certainly benefits from a compositional style, but for anything involving complex state control (interfaces, objects, networking, i/o, whatever) it is not so appealing. I think the latter tasks are what Pierre means by "the working programmer" -- (a rather loaded term in the ML world? ;-) ) > 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. Some invisible uses of side effects are highly compatible with a functional style, e.g. memoizing and building tables based on an environment, and certainly John uses these effectively in his programs. Externally visible effects are, of course, to be avoided when using a compositional approach, as Pierre suggests. So you're both right, and that's just why CaML is so appealing: when doing structural data manipulations it supports the functional model, but it also supports state-based programming in a very traditional fashion (mutable record fields, objects, arrays, for-loops, while-loops, begin-end statements all being part of this). For example, I would teach both styles as part of a CaML programming course, and I frequently use both styles in different modules of the one program. Don