Skip> * Future extensions like pluggable virtual machines will be harder
Skip> to add because their byte code compilers will be harder to
Skip> integrate into the core
Tim> If you're picturing adding this stuff sprayed throughout the guts
Tim> of the existing com_xxx routines, we've got different pictures in
Tim> mind.
This was precisely my example, because that's the way I implemented the
return warning stuff, by modifying the com_xxx routines. I believe that's
the wrong way to go in the long run, and I see by the rest of your message
you feel the same way as well. To the greatest extent possible, I think
this stuff should be implemented in Python. (We may disagree on that
point.) Being able to plug in new parse tree analysis/transformation
modules between parse tree creation and code generation could at least be
controlled from Python.
Skip
P.S. Something I just noticed: Since the node typedef (node.h) and the
macros that manipulate nodes are shared across multiple files shouldn't they
be named something slightly less likely to clash with other packages?
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