Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!ukc!dcl-cs!nott-cs!anw From: anw@nott-cs.UUCP Newsgroups: comp.lang.misc Subject: Re: H.O.Functions + Polymorphism Message-ID: <371@tuck.nott-cs.UUCP> Date: Thu, 16-Jul-87 13:50:51 EDT Article-I.D.: tuck.371 Posted: Thu Jul 16 13:50:51 1987 Date-Received: Sat, 18-Jul-87 11:34:17 EDT References: <...> <2637@crcge1.UUCP><1345@ogcvax.UUCP> Reply-To: anw@nott-cs.UUCP (Dr A. N. Walker) Distribution: world Organization: Maths Department, University of Nottingham, ENGLAND. Lines: 71 In article <1345@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >Well, imperative languages do not support these features, (higher-order functions & lazy evaluation) > and higher order >functions, at least, are a central issue to functional programming. Because >imperative languages are modeled somewhat after the machines they run on, >having storage locations, addresses and state, such concepts are really >incompatible with them. [...] > One common feature of languages which directly support higher order >functions is that 'plus' can be partially bound to form a new function -- [ example omitted ] >This view of functions is thoroughly incompatible with that of any imperative >language. The only reason why I can't use in Algol the `plus' function: PROC plus = (INT i) PROC (INT) INT: (INT j) INT: j+i; and then declare the `plus 1' function: PROC p1 = (INT k) INT: plus (1); is that the Report defines the scope of the body of `plus' in a way that makes the returned function too `local' to be identified with `p1'. A common (:-)) extension makes all this perfectly possible using partial parametrisation. See "Partial Parametrization" by C. H. Lindsey in Algol Bulletin, AB37, pp24-26, July 1974. For example, PROC plus = (INT i, j) INT: i+j; PROC (INT) INT p1 := plus (1, ); IF p1 (6) /= 7 THEN print (("Oops!", newline)) FI; Lindsey also gives a guide to implementation and the `functional composition' example (amongst others): PROC compose = (PROC (REAL) REAL f, g, REAL x) REAL: f(g(x)); PROC (REAL) REAL sex = compose (sqrt, exp, ); So HOFs were `old hat' in imperative languages by 1974; no incompatibilities there! >Now, combine this idea with polymorphic types. [...] By sheer coincidence, on pp26-29 of the same Algol Bulletin you will find discussed examples and the implementation (again in an imperative context) of modals. I've pinched the following example: PROC sort = (MODE Z, REF [] Z vec, PROC (REF Z, REF Z) BOOL swapped) VOID: FOR i FROM UPB vec BY -1 TO LWB vec + 1 DO FOR j FROM i TO UPB vec WHILE swapped (vec[j-1], vec[j]) DO SKIP OD OD; Nothing very incompatible there, either. > [...] However, lazy evaluation is not supportable in >imperative languages as it is an 'evaluate on demand' strategy for function >parameter evaluation. All imperative languages evaluate the arguments to >functions before the function is invoked. [ ... ] Not supportable? It is true that the historically important compilers of the historically important imperative languages do not support lazy evaluation; but then, nearly all of them, from Fortran to C and Ada, have had goals which include speed, efficiency, and the like. There is no vital reason why the semantics of any new imperative language should not encourage lazy evaluation, or why one should not write a `lazy C' compiler (though don't expect it to be easy or particularly useful). Andy Walker, anw@maths.nott.ac.uk