[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[hendrik at topoi.pooq.com]

On Wed, May 28, 2008 at 04:26:10AM +0000, Jay wrote:
> > The CDC Algol 68 compiler had a trick for recognising expired scopes 
> Hendrik -- but then again there is that heap allocation cost..

But only for the blocks closest-containing procedures whose addresses 
are taken.  That is relatively rare, and it will not cause heap allocation 
for anyone that does not take addresses of nested procedures.
>  
> This is also a step toward, like, heap allocated stack frames, except 
> the garbage collected heap is only being used for its "lifetime 
> features" and not its ability to store anything (other than 
> lifetime/liveness).
>  
> As I understand..and this is maybe crazy...a straightforward Scheme implementation -- with no static analysis -- and "Stackless Python" take that next step -- all frames are heap allocated and garbage collected, and therefore a pointer to a nested function can outlive its original context. Neat but seems expensive. Perhaps can be fast enough.
> I like the canonical Scheme example:
>  
>   (define make-adder (x) (lamba (y) (+ x y)))  
>   (define add5 (make-adder 5))  
>   (add5 3)  
>  
>   => 8  
>  
> implies make-adder's frame that contains "5" is heap allocated and then "add5" is a heap allocated chunk that contains merely that pointer and a pointer to the nexted function.
>  
>  > procedure to a single-pointer callback. This functin will have to be   > rewritten for each platform, and can allocate the necessary   > dynamically-genereated code on the heap (or, of course, on the stack, if   > possible on that platform). As for portability, it's certianly no  

> I think it's easy enough to generate the code, the problem is where to put it.
> Stack is not necessarily executable, heap is more expensive to allocate.
> But in this forum I'm always contradicted on that last point, so it could just be in the heap.
> Note that the heap isn't necessarily executable either.

Id you can't write into dynamically-allocated code space, you may as 
well forget about JIT compilers.  Well, I suppose there could be 
machines that can't have JIT compilers.
 
Actually, if you're talking to C, you should be able to follow the 
same restrictions that C uses.

>  
> I don't think breaking the existing compatibility with C function 
> pointers is good.

Until this discussion started, I never dreamed there was any 
compatibility with C functino pointers except for non-nested procedures.  
This all came as a surprise to me.

> In fact, I dare suggest that C interop should be aided by the Modula-3 
> compiler generating "headers" for C.
> Really just a possible part of any "C backend". :)
>  
> If the type system is strong enough..having two separate types for C 
> function pointers and Modula-3 function pointers might be viable. But 
> you'd have to review all the "loopholes". Again probably a losing 
> effort.

Just like C strings and Modula 3 strings?

>  
> As I've said a few times, I'm fairly content to leave this all alone. 

I, too.  But I thought it ws worth pointing out that there is a 
conceptually clean solution, especially since conceptually clean 
practicality is one of Modula 3's hallmarks.

-- hendrik