Dan Sugalski wrote:
At 11:03 PM -0700 8/21/04, Steve Fink wrote:
I am experimenting with registering my own compiler for the "regex" language, but the usage is confusing. It seems that the intention is that compilers will return a code object that gets invoked, at which time it runs until it hits an C<end> opcode. But what if I want to return some values from the compiled code?
Here's what's supposed to happen.
The compile op only compiles the code passed in, it doesn't execute it. The returned sub object represents the entire code chunk that was compiled, and likely ought to be immediately executed itself.
As a perl example, the eval function should give code like:
compiler = compreg "Perl5" eval_pmc = compile compiler, my_source eval_pmc()
though the eval_pmc() call ought to check and see if it got anything in return.
This does mean that if you skip the invocation of the returned PMC that things may not happen. This is fine. And for many languages the returned PMC won't actually do anything at all when invoked.
It's important to note that the returned PMC does *not* represent any particular sub in the source -- rather it represents the entire source module. So if the language was C, for example, the returned PMC wouldn't do anything since C doesn't allow you to have code outside functions.
Could not variable initializers require code outside of subs to be executed even in C?
Absolutely. The C compiler module can do whatever it likes when it compiles code -- it's certainly acceptable for it to run code as well. (Heck, there's nothing to stop you from having a compiler module which reformats your hard drive if you feed it Intercal) The returned PMC, which represents the entire compiled code module, can also do something when executed, and likely should.
The issue of elaboration (to borrow a word from
the Ada world) always needs to be considered in cross language
programming. Only one language can own "main" and some provision always
needs to be made to invoke the outside-of-subs set-up code the other
langauges need. This issues applies not only to "eval" but to things
like loading dynamic libraries. The problems that leo and Stephane are
having with gtk are related to this as well, i.e., it looks like parriot and Gtk are fighting over who is "main".
Yeah, we've got to un-main ourselves better than we do. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
