Lambda the Ultimate

AFAIK, Pascal doesn't have higher-order functions. You can define functions locally, but not return (a pointer to) a function from a function.

To double-check this, I looked at the Extended Pascal standard here, and found no mention of anything resembling higher-order functions; in particular, there appears to be no way to denote the type of a value which is a function. Maybe one can represent functions, though, in a way that forgets the parameter and return types (besides representing them as, say, strings :).

It may well be the case that variants like Turbo Pascal support higher-order functions, though.

MODULE Test; IMPORT Out;
TYPE F = PROCEDURE (): INTEGER;
VAR f: F;
PROCEDURE Number(): INTEGER; BEGIN RETURN 1; END Number;
PROCEDURE FF(): F; BEGIN RETURN Number; END FF;
BEGIN
   f := FF(); Out.Int( f(), 1 );
END Test.

Ada (that's Ada95, of course) funargs have to be named routines, and you can't pass around pointers to routines of deeper scope ("downward closures"). Ada has very strict rules about the scope of access types and access values ("access" in Ada means "pointer"), so it's quite hard to take make a pointer to an inaccessible subroutine. However these restrictions are too extreme, and are the result of implementation difficulties in compilers that use displays.

There are proposals for fixing the restrictions of procedure parameters for the 200Y revision (I recommend reading the "!discussion" section if you are interested in the details of the Ada situation).

I hope the above is clear (I am bit tired at the moment), if not the link I gave contains all the gory details..

By `funarg' I guess you mean an argument which is a function. What is the type of such an argument? I didn't see anything in the (Extended) Pascal type syntax which would allow this.

GNU Pascal supports Standard Pascal's procedural parameters:

procedure DrawGraph (function f (x : Real) : Real);

and

An important feature of Standard Pascal (but not BP) that GPC also supports is the possibility to pass local routines as procedural or functional parameters, even if the called routine is declared far remote. The called routine can then call the passed local routine and it will have access to the original caller's local variables.

program LocalProceduralParameterDemo;
procedure CallProcedure (procedure Proc);
begin
  Proc
end;
procedure MainProcedure;
var LocalVariable: Integer;
  procedure LocalProcedure;
  begin
    WriteLn (LocalVariable)
  end;
begin
  LocalVariable := 42;
  CallProcedure (LocalProcedure)
end;
begin
  MainProcedure
end.

See sections 6.7.3.4 and 6.7.3.5 on these parameters. They do not appear to be defined as "types" in the manual, but they are listed as allowed parameters.

The text about "the procedure shall be one contained by the activation" is the explanation about these being downward funargs, i.e. they are functional arguments but cannot escape the dynamic extent of their activation record on the stack.

Here's the document straight from the source which also describes procedure and function parameters. (And has an alarming number of holes in general, on just glancing through it.)

It seems like there are several aspects worth considering:

* The visual-widget aspect. For example, the output is assumed to be a gui, and may include things like charts.

* The visual-editing aspect. For example, you can point at a spreadsheet and start typing expressions -- kind of like a repl on steroids.

* The dataflow aspect.

Anybody have any thoughts on these ideas? Experience with a language that incorporated one or more of these ideas in an interesting way?