🚀 go-pugleaf

wil@ittpub.nl (Wil Evers) wrote:
[snip:the implementation of nested functions]
>Personally, I don't think this difference in execution model is enough  
>reason to forget about nested functions. There are several solutions to  
>this problem:
>
>- Disallow nested functions to directly access the locals from one of its  
>enclosing scopes, as Lawrence Kirby suggests. This is my favorite because  
>it's easy to understand and enforces explicit passing of access to local  
>variables.

Once upon a time, I proposed function literals to the committee; however it
suffers the same problem as nested functions--references to non-local
automatics. I personally wouldn't mind this this restriction at all; however, I
believe that programmers in general would expect to be able to reference all
objects in the scope within which a nested function is declared. Also, this
capability is central to why some people want nested functions. To implement
them otherwise would be a dirty trick.

>- Disallow calls to the same nested function from different lexical  
>nesting levels. This is probably the least attractive option because users  
>will have a hard time grasping this and compilers have to check for it.

Agreed.
 
>- Use a different execution model for nested functions only. This is what  
>most Pascal compilers do. In C, there would be major problems in  
>expressing pointers to such functions. We would need a syntax to express a  
>'pointer to function nested in <this other function>' or live with a big  
>loophole in the type system.

Ugh. Some C compilers have this extension. These function pointers have a
special operator (e.g., "!", I think) used to declared the pointer so that the
compiler can generate different code for them.

>- Use the nested function execution model for all functions, nested or  
>not. Here, we would have problems in linking with existing pre-compiled  
>libraries, but we could probably do with only one pointer to function type  
>(which would still not be completely type-safe, because the context in  
>which a function is called can't be easily checked now).

UGH.

[snip]

In summary, it ain't gonna happen.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.