3 ms·
So, I know very little about the practical implementation of a non-trivial interpreter (read: next to nothing), but... it's difficult for me to understand why t
by EpicEng 12y ago
So, I know very little about the practical implementation of a non-trivial interpreter (read: next to nothing), but... it's difficult for me to understand why this would be the case. What is the reasoning behind the interpreters lack of semantic awareness? Can't it, in the most simple case, see that the block is not being modified or accessed in any way and optimize the reification out?
- chrisseaton 12y agoIt seems like it's obvious that it should be able to remove the allocation of the block, however as with everything in Ruby there are edge cases. What happens if you're halfway through executing this method, you've not allocated the block, and somebody wants to start a debugger? Then you have you go back and somehow recreate the Proc as if it was always there. Same thing if someone uses ObjectSpace to look for all live Procs.
- EpicEng 12y agoHuh. Is it standard in interpreted language land to avoid optimizations in case for the debugger use case? Seems like that would rule out a ton of potential optimizations...
- chrisseaton 12y agoIt doesn't rule them out, you just need a more sophisticated implementation, using things like JIT compilation.
- vertex-four 12y ago> Is it standard in interpreted language land to avoid optimizations in case for the debugger use case? Yes. Otherwise, you'd have to have separate "being debugged" and "not being debugged" runtimes that keep track of different information and do different things, and it's not unlikely that you'd end up with programs doing different things as a result. You can actually access debugger information from inside the program, and it's not that uncommon to do that.