🚀 go-pugleaf

volpe@bart.crd.ge.com (Christopher R. Volpe) wrote:
>In article <446ttn$deg@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>>
>>>- 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.
>
>I assume this implies that nested functions can not be recursive?

Yeah, I guess you're right. I function could call itself, but nobody else could
call the function in the first place to get the ball rolling because the two
calls would be at different "lexical nesting levels."

>>>- 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.
>
>Ok, I'll bite: What happens if the nested function references auto variables
>in the enclosing function, and then the nested function is called through a
>function pointer when the enclosing function is not active and said auto
>variable doesn't exist?

Currently, the value of a pointer to an automatic that is no longer guaranteed
to be reserved is indeterminate. Likewise, referencing an automatic that is no
longer reserved would result in undefined behavior. In other words, it does
what you might think--your program runs off into the weeds. :-)

>>>- 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.
>
>Yeah. Does my above question apply equally well in this case?

Yes. I think what you are getting at is that some garbage-collecting languages
form closures, e.g., Lisp and Clipper, where the object is reserved as long as
there is at least one reference to it. The result is that one can reference an
object even when it is out of scope. C isn't like this, as you know.

-- 
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.