How does perl handle HLL C<eval>?
Michal Wallace
> The subject says it all.
>
> As parrot is designed to be targetted by many langauges,
> how will it handle 'eval' opcodes for those different languages?
>
> Shell out to a seperate process?
You could do that, or you can provide a C-based
compiler as a PMC or you can teach your language
to compile itself... Or you can even write your
language in some other language that targets parrot. :)
> Nigel.
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
nigels...@btconnect.com
As parrot is designed to be targetted by many langauges,
how will it handle 'eval' opcodes for those different languages?
Shell out to a seperate process?
Nigel.
Joseph Ryan
As far as Perl6 (which will be written in Perl6) goes, an easy
solution is to design the compiler so that compilition to imcc
can be done with a generalized function call, and then link in
the perl6 compiler as a module. Eval can then just be a simple
wrapper around that, something like:
.pcc_sub _eval non_prototyped
.param String code_to_eval
.param PerlHash options
.pcc_begin prototyped
.arg code_to_eval
.arg options
.pcc_call _compile_perl6_code
.local string IMCC
.result IMCC
.pcc_end
.local Sub _current_eval
.local PerlUndef result
compile _current_eval, "IMCC", IMCC
invokecc _current_eval
restore result
.pcc_begin_return
.return result
.pcc_end_return
.end
Something similar could be done with a C-based compiler and NCI.
- Joe
Leopold Toetsch
> As parrot is designed to be targetted by many langauges,
> how will it handle 'eval' opcodes for those different languages?
It'll be a sequence like this
loadlib Phandle, "your shared lib"
dlfunc Pcompiler, Phandle, "compile"
compreg "language", Pcompiler # 1)
...
compreg Px, "language" # get a compiler reference
compile P0, Px, "the source" # compile source code
invoke # eval
1) is currently not yet implemented, its a variant of register this
subroutine as a compiler for "language".
If the compiler is written in PASM, there is another variant:
compreg "language", _my_compiler # register this Sub as a compiler
All other pieces are working.
> Shell out to a seperate process?
That's another way.
> Nigel.
leo
Dan Sugalski
>As far as Perl6 (which will be written in Perl6)
That, as they say, turns out not to be the case. Most of perl 6 will
probably be written in C...
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>The subject says it all.
As Leo's pointed out, that's what the compile op is for. It takes
both a string with the source to compile as well as the name of the
compilation module to pass it to. This currently works with the
modules "PIR" and "PASM" for, well, PIR and pasm code, but it will
work with any other language that can generate standard bytecode
segments. (I really, *really* ought to get Forth thumped into shape
enough to do this as an example)
The (currently nonfunctional) compreg op is there to register new
compiler modules with the interpreter, which is how loaded compiler
libraries will make themselves available to parrot.
At some point you'll probably be able to do, from within perl, something like:
eval :language(LISP) "(defun foo ...)";
or something more or less like that. (Assuming someone builds a lisp
compiler for parrot, of course)