Re: procedures as parameters

[anw@nott-cs.UUCP]

In article <12212651166.12.BRYAN@SU-SIERRA.ARPA> Bryan@SU-SIERRA.ARPA.UUCP
writes:
> Could some of you C and/or Algol hackers out there give me an example of
> [...] an algorithm where the subprogram, or actual parameter, cannot be
> determined until run-time.

	I'm not sure whether this is too simple, or perhaps not at all what
you had in mind, but many pre-compiled library modules have this property,
assuming that by "until run-time" you mean "at compilation time".  For example,
you might have

	PROC simpson = (PROC (REAL) REAL f, REAL a, b, eps) REAL:
		(# code to integrate "f", a real function of a real parameter,
		   from "a" to "b" within tolerance "eps" by using Simpson's
		   rule # SKIP);

shoved into a library [and therefore compiled in complete ignorance of what
particular functions might appear], after which the user could write in *his*
program things like

	x := simpson (sqrt, 1, 2, 0.00001);
	y := simpson ((REAL x) REAL: x * exp(x), x, x+1, exp(-x));
	z := simpson ((REAL x) REAL: simpson (sin, 0, x, 1e-7), 0, 1, 1e-7);
	w := simpson ((z>0 | sin | cos), 0, pi, 1);
	v := simpson (FRED 7, -1, 1, 0.1)

where FRED was an OP (INT) PROC (REAL) REAL.  It's possible in Algol to
write operators and functions that deliver functions or procedures, but
unfortunately the scoping rules prevent this being of more than limited
use*.  Some compilers implement extensions such as partial parametrisation
that make it sensible to compose functions as the program proceeds, in
which case it is clearly impracticable (in general) for the compiler to
list all the functions that "simpson" might be used with.
							-- Andy Walker

* For example, you can't do things like

	OP (PROC (REAL) REAL f, g) PROC (REAL) REAL COMPOSE =
		(REAL x) REAL: f (g (x));
	PROC (REAL) REAL sincos = sin COMPOSE cos;
but
	OP (PROC (REAL) REAL f, g) PROC (REAL) REAL OR =
		IF random < 0.5 THEN f ELSE g FI;
	PROC (REAL) REAL sorc = sin OR cos;

is fine.  Spot the difference!