Resurrection of whiteknight's eval_pmc branch
Patrick R. Michaud
pmichaud at pobox.com
Mon Feb 18 17:11:20 UTC 2013
On Mon, Feb 18, 2013 at 08:16:41AM -0500, Andrew Whitworth wrote:
> The way the Eval PMC worked was that it returned a list of Subs, and I
> think the one at index zero was the sub marked :main.
No. The Eval PMC contains subs in the order in which they appear in
the source, regardless of which sub is marked ":main".
pmichaud at kiwi:~/p6/parrot$ cat z.pir
.sub 'main' :main
.local pmc fh
.local string ypir
# read source to be compiled from y.pir
fh = new ['FileHandle']
ypir = fh."readall"()
# display y.pir
say "y.pir source:"
# compile y.pir
.local pmc pirc, ypbc
pirc = compreg "PIR"
ypbc = pirc(ypir)
# display type of object returned
print "typeof object returned from PIR compiler: "
$S0 = typeof ypbc
# display sub at position zero
print "sub at position zero: "
$P0 = ypbc
pmichaud at kiwi:~/p6/parrot$ ./parrot z.pir
.sub 'two' :main
say 'two :main'
typeof object returned from PIR compiler: Eval
sub at position zero: zero
pmichaud at kiwi:~/p6/parrot$
In the above example, the first element of the Eval PMC (the one
at position zero) is "zero", while .main_sub() would seem to return
"two", which is not what NQP/Rakudo would be expecting or wanting.
> The PackfileView
> PMC has a method .main_sub(), which does the same thing more
> explicitly. At least, that's how I remember it. so it's the same Sub
> being executed, we just get access to it in a different way.
No, it's not the same sub (see above). And in the case of NQP
and Rakudo, we generally need access to the first sub in order
to set its outer lexical context or other properties, not because
it's the "main" sub or the one that is to be executed.
More information about the parrot-dev