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@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']
fh."open"("y.pir")
ypir = fh."readall"()
fh."close"()
# display y.pir
say "y.pir source:"
say ypir
# 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
say $S0
# display sub at position zero
print "sub at position zero: "
$P0 = ypbc[0]
say $P0
.end
pmichaud@kiwi:~/p6/parrot$ ./parrot z.pir
y.pir source:
.sub 'zero'
say 'zero'
.end
.sub 'one'
say 'one'
.end
.sub 'two' :main
say 'two :main'
.end
.sub 'three'
say 'three'
.end
typeof object returned from PIR compiler: Eval
sub at position zero: zero
pmichaud@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.
Pm
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
