> Would this functionality working like I wish it did be difficult?
First, as best as I can figure, the current functionality is seriously
broken. It's reaching into a interpreter stack frame at the offset
associated with x. That just happens to be the offset associated with 'a'
during your my_addr()/your_addr() invocations, which is why the output is
a doubling of 'a'.
Indeed, I've confirmed that if your outer function had an additional
argument that comes before 'x', then the my_addr()/your_addr() invocations
crash.
To fix this, it makes sense that for functions defined inside other
functions, there's a clear binding model. The only trick is what
that model should be. If it's bind-on-function-creation, then you'd
get the semantics you desire. But I suspect there are other uses
for such interior funtions where bind-on-application is handy - *providing*
of course that the interior function doesn't escape to the exterior like
it does in your example.
My proposal would be to introduce bind-on-function-creation semantics,
and if later we find we sometimes want bind-on-application semantics,
introduce that using an attribute.
But there's still the "would this .... be difficult" question. I suspect
it's going to be messy. I'm having a hard time seeing how it doesn't
involve a full parse-tree traversal of the interior function's body during
creation. (And I leave the problem of the interior function itself having
an interior function as an exercise for the reader. :-)
Vern
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
