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