On Mon, Feb 18, 2013 at 2:14 PM, Patrick R. Michaud <pmich...@pobox.com> wrote:
> At the moment NQP/Rakudo do not emit :main subs, but they once did, and
> if we ever attempt to do pre-compiled standalone .pbc/.exe files
> instead of always invoking Perl 6 source code, then NQP/Rakudo will
> again be generating subs with :main.
> Okay, as long as it's custom tag*s* to mark the sub*s* we want.
> We need to be able to locate both the "Perl 6 mainline sub" and a
> "Parrot sub to be automatically invoked when run via Parrot command line",
> and they are generally not the same sub. The current pull requests
> to NQP and Rakudo definitely confuse the two, thus I'm rejecting them
> as they stand now.
You can use the :tag('name') syntax to give any Subs you want the tag
names you want. PackFileView then has method to look up Subs by tag
name. Currently ":load" and ":init" are functionally identical to
":tag('load')" and ":tag('init')". If you're going to be changing
around the way you generate code in the future, the PackFileView PMC
is going to be a much more flexible tool to use than Eval.
Currently the "perl 6 mainline sub" you're talking about, if I
remember correctly, is the first Sub in the file and is not tagged. To
get access to this sub, you can use any of these:
pf.main_sub()
pf.all_subs()[0]
Either is fine. The first relies on current :main Sub selection rules
(first one tagged :main or first Sub if none are tagged), but the
second relies on positioning of the sub in the file. Both seem
distasteful to me (but then again, the current code uses Eval[0],
which is exactly the same). A better option would be to tag your
mainline sub with something obvious:
.sub whatever :tag("perl6mainline")
...
.end
And later access it with:
pf.subs_by_tag("perl6mainline")[0]
(This assumes you only have one sub with that tag. If you have
multiples, you'd need a way to differentiate. But then again, this
wouldn't even be possible with Eval)
In either case, performance is better with this option and it gives a
route forward to remove the Eval PMC. I recommend we find some way to
make the Rakudo portion of the patch palatable, because the Parrot
side of this mechanism is rock solid and has some benefits to program
startup performance.
--Andrew Whitworth
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
