[stack] Re: Parameters: ordered versus named

--- In [email protected], John Cowan <cowan@...> wrote:
>
> pml060912 scripsit:
> 
> > 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. 
> 
> That's dynamic scoping (not to be confused with dynamic *typing*) 
and
> it is a Really Really Bad Idea, because reasoning about the behavior
> of programs becomes insanely difficult.  You wind up not being able 
to
> know where the value of a variable is set unless you know the exact
> path by which it was called, and no procedure can guarantee that the
> values of its parameters are safe from tampering unless it never 
calls
> any other procedure.

That depends on what else is available to change them. As far as I 
can see, it's less risky in spreadsheets than in other languages 
since - depending on what base you have for building the formulas - 
formula execution needn't change the cells you allocate for that use 
(unless you foolishly use the same cell for one parameter as for the 
formula using the parameter!). But as I said, at this point I'm just 
mulling over ideas.

  What's more, that particular *implementation*
> of dynamic scoping (known as "shallow binding") only works in a 
single
> thread of control; if there are multiple threads, it goes horribly 
wrong
> in all sorts of ways.
> 
> Lexical scoping, in which variables only exist within the particular
> portion of the program that declares them, is a far superior regime.
> There are occasional uses for dynamic scoping here and there, and
> some languages support it as an alternative to lexical scoping for
> restricted use (Perl and Common Lisp, notably; also because of 
backward
> compatibility).  But it's hard to believe that any modern work on
> interpreters would recommend it.

P.J.Brown wrote the first edition in 1979, emphasising 
implementation. He wasn't recommending this technique for the 
language design, but as an implementation technique for passing 
parameters to subroutines without having to implement the subroutine 
bodies specially. You would constrain the language in other ways to 
avoid some of these problems, for instance having an extra level of 
indirection in descriptors would allow it to act more like parameter 
handling in C. Brown also suggested having variables associated with 
subroutines and only allowing access to other variables by giving 
them what amounts to pathnames. On checking, I find that Brown only 
recommended this technique for subroutines, not functions, and he 
didn't specify the foo(x=a, y-b, z=c) notation for calling.

I realised that it wasn't the best way to extend Cobol (say) to make 
it convenient for compiling itself, but it would have been a 
realistic approach if the extended version was only used in house 
with great care and not released. PML.