OK, I've tried out the latest commit. The changes to the MV implementation seem fine to me, though I haven't tested or analyzed them other than to confirm that our code isn't affected. I like that the generated code is simpler, and I agree with your choice to not support passthrough unless/until we can find a correct implementation that isn't too complicated. In the absence of that, the latest version seems like a good compromise and an improvement over what we had before. It's a reasonable place to stop.
That being said, there's one point that's still bugging me because I don't see it yet:
Other exit points from a function are throws and control reaching the end of the function. So both are going to have to get instrumented.
I sketched an argument why extra instrumentation isn't needed in these two cases. If that argument is wrong (which it may well be) then we should be able to give examples where the pure global-variable (GV) design fails in the absence of such implementation. That is:
(1) An example where an uninstrumented throw causes the GV implementation to be wrong; and
(2) An example where an uninstrumented function exit causes the GV implementation to be wrong.
I don't think any of the examples in the thread satisfy (1) or (2), nor have I come up with any. Can you? I'd like to see them.
Daniel
On Thu, Sep 13, 2012 at 12:00 AM, Vladimir Sedach vsedach@gmail.com wrote:
Ok, I just pushed the promised change that removes mv passthrough and replaces the function object property setting with a global variable. I'm very happy with this approach - the generated code is now much cleaner than it used to be.
Please try the changes out. If there aren't any issues, this is going in to the next release, which I'd like to make by the end of the month.
Happy hacking, Vladimir
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel