Steve Fink <[EMAIL PROTECTED]> wrote:
> On Sep-20, Dan Sugalski wrote:
>>
>> Now, the issue is how to actually build a compiler. Right now a
>> compiler is a simple thing -- it's a method hanging off the __invoke
>> vtable slot of the PMC.
First we should unify the return value. We currently have basically two
kinds of compilers:
1) return an Eval PMC (builtins PASM, PIR)
2) user compilers which return a subroutine
Both return invocable subs, but terminating the run-loop started by 1)
needs an C<end> opcode. That's more a historical hack then useful.
Following calling conventions, code returned by 1) should also run in the
caller's run-loop and terminate by invoking the return continuation.
OTOH it depends on what granularity we allow for evaled code. If that's
always a closure, it should follow calling conventions. If its more
fine-grained (statement or expression only) some special treatment might
be in order.
Finally there is some nasty kind of perl5 code, which is currently
covered in a special way with the C<branch_cs> opcode:
# LAB:
# $i++;
# eval("goto LAB if ($i==6)");
# print "$i\n";
Dunno, if we can force the use of a continuation with such kind of code.
> [ ... ], then I can
> see some utility in having a separate C<compile> op,
I think a special opcode is ok, the more that we possibly want to pass
in some arguments too, or ...
> ... (Though I wonder if you
> might want sometimes use a filename rather than a
> string-containing-enormous-chunk-of-code).
Yep.
> A question: when last we talked about this, you mentioned that you
> didn't envision it being useful for compilers to take arguments.
I think we need first a scheme to be able to pass on language specific
command line arguments. Something similar that e.g. gcc does for passing
arguments to the linker, or:
./parrot --perl6 .. perl6 options .. --parrot .. parrot options -- ..
The HLL-specific part of the commandline could be collected in an $HLL-argv
and be passed to the compiler in C< P5 >.
Further we should have registered file types, so that e.g.
./parrot f.py
does the right thing. There is currently some code duplication in the
startup of imcc/main.c and in code used by the C<load_bytecode> opcode,
with hard-coded compiler selection based on the extensions .pasm, .past,
and everything else meaning .imc.
leo
