On Tue Jul 04 12:21:06 2006, [EMAIL PROTECTED] wrote: > Currently, if you use IMCC inside embedded parrot (eg. when compiling > via PGE), when a syntax error occurs, imcc calls Parrot_exit (or > downright exit() -- see imclexer.c)), and it terminates the > interpreter right there without any chance of recover. > > However, we can't easily make that throwing an exception, because > IMCC currently relies on a lot of static globals to carry state, and > cannot reliably restore them when an error occurs. (grep for > "static" and "FIXME global" in the IMCC tree.) > > Moreover, the :immediate feature, currently unused (except to load > dynamic lex pad, as a backdoor workaround for the design) and > undocumented, allows running arbitrary code inside the .pir->.pbc > emitter; that means each .pir compilation can potentially affect the > state of the environment. > > In short, a .pir file can compile to drastically different .pbc file, > depending on the phase of the moon, etc. > > Currently in all Parrot-targetting languages, only Perl 6 has that > kind of evaluation-during-compilation feature, via its BEGIN block; > however, due to Perl 6's doctrine of separate compilation, the BEGIN > block has be compiled separately as another .pbc anyway; that means > nobody has a legitimate use of :immediate at this point.
This feature is needed for how parrot currently handles dynamic pmcs. If :immediate is deprecated, part of that deprecation needs to include keeping languages which use dynamic pmcs (perl6, tcl) functioning. > I argue that :immediate should be retired, and static globals should > be removed from IMCC. There is no drawback (as currently there are > no real uses and it's undocumented), and the benefits are: Apparently non-real uses exist. Documented or not, its use is currently required. Drawbacks include architecting a new way to handle dynpmcs, and then updating the existing code base to use them. > - External non-parrot tools can manipulate .pir without exposing > themselves to the security risks of carrying a full Parrot interpreter. > - IMCC can regain the ability to compile .pir to .pasm. > - It will be safe to recover from a .pir parsefail for Parrot embedders. > - .pir->.pbc is made into a deterministic process, which makes .pir > fingerprinting possible. Note: I'm not arguing against any of these pros. Just pointing out the state on the ground. Regards.
