Phillip J. Eby wrote: > Hm, actually I think I see the answer; in the case of module-level code > there can be no "anonymous local variables" the way there can in > functions. Why not? There's still a frame object associated with the call of the anonymous function holding the module's top-level code. The compiler can allocate locals in that frame, even if the user's code can't. > I guess you'd need to also have a "reset stack to > level X" opcode, then, and both it and the set-handler opcode would have > to be placed at every destination of a jump that crosses block > boundaries. It's not clear how big a win that is, due to the added > opcodes even on non-error paths. Only exceptions and break statements would require stack pointer adjustment, and they're relatively rare. I don't think an extra opcode in those cases would make much of a difference. -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing at canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4