[stack] Re: Parameters: ordered versus named

--- In [email protected], Manfred Von Thun 
<m.vonthun@...> wrote:
>
> For a long time I have been interested in the difference
> between the standard kind of lambda calculus languages
> and the concatenative languages. Only recently did it
> occur to me that there is a third class which has been around
> for some time. The three differ in how they treat actual
> and formal parameters in definitions of functions and in
> calls of functions. At one extreme are the concatenative
> languages, at the other extreme those in the third class.
> The standard lambda calculus languages are half way
> between these two extremes.
.
.
.
At the other extreme there should be languages
> which do not use  order at all but rely on names both
> in the body and in calls. Are there such beasts?
> 
> In such languages definitions would again look as in
> lambda calculus languages:
> 
> DEFINE foo(x,y,z)        # head of definition
>    = ...x...y...z...          # body of definition
> 
> As before, you can change the order of the parameters
> without any need to change the body of the definition.
> But a call would look quite different: instead of relying
> on the order of the formal parameters, use their names
> as assignment statements, and make the assignments
> in any order. Hence any of the following would be OK
> as a call:
> 
> foo(x=a; y=b; z=c)
> foo(y=b; z=c; x=a)
> foo(z=c; y=b; x=a)
> 
> and so forth, a total of six possible combinations. All such
> calls would be equivalent. To summarise: body and call
> are done by using the names of the formal parameters.
> My understanding is that there are some languages which
> allow this kind of notation (Common Lisp ?, Ada ?) but
> I cannot remember any details --- anyone?? But as far
> as I know these languages use standard positional notation
> by default and allow this other notation only as a
> convenient variation. I have never heard of a language
> in which this way of calling is standard. Anyone??

That looks like something I came across in P.J.Brown's "Writing 
Interactive Compilers and Interpreters", although I forget if he 
stated it explicitly or just implied it. In essence, he suggested 
handling parameters and local variables by a "don't care" method, in 
which they were really global variables like any other, only their 
values were stacked/reinitialised and then restored on call/return. 
Then the function call construct is little more than a subroutine 
that can return a value, and foo(x=a; y=b; z=c) is a macro for the 
pushing and popping of global variables x, y and z on either side of 
gosub foo. The function needs no special declaration, either.

I actually looked into this approach for its smaller 
implementation "footprint" in two areas:-

- extending awkward languages like Cobol so that they could 
comfortably support their own compilers (the released version would 
have had the extensions disabled); and

- making user defined functions easy to implement in a spreadsheet.

The latter relates to my musings on where to go next in paper 
exploring for Furphy, since a spreadsheet would make a comfortable 
programming interface for a functional programming language. PML.