> -----Original Message-----
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Austin Hastings writes:
> > # Each "broad class" of upcased block is an execution group. The entries
> > # in each execution group are not guaranteed to run in any
> particular order,
> > # and in fact may run in parallel on a multithreaded perl.
>
> Would you guys cut that out! Nothing's running in parallel unless I
> tell it to! Or peraps, Nothing's running in parallel if I tell it not
> to! In either case, it could be an easy, global pragma overridable
> locally[1].
True. But in a potentially-parallel environment, it's good to specify expected
behavior. In this case, the expected behavior is such that if I say
perl6 -P (or --parallel) myscript.p6
I know what the result will be, because the nice man on p6language specified it. And
if that never happens, well, the spec didn't hurt anyone.
> > # Thus, all "BEGIN" blocks in a file are effectively catenated
> and added to
> > # an overall "BEGIN" execution group. All the separate BEGIN
> entries have
> > # the same initial priority(10), so they will run in whatever
> order suits
> > # the P6 runtime.
> > #
> > # The C<go> property introduces changes to the execution group and/or
> > # priority of the block in question. (Note that different priorities may
> > # be attached to different blocks within the same file. Doing so creates
> > # separate execution bundles, and breaks any guarantees about order of
> > # execution.)
> > #
> > package OtherPackage;
> > BEGIN will go <first> {
> > print "first!";
> > }
>
> And what's with all the weird notation? Perl 6 naturally supports this
> without adding new syntax:
>
> BEGIN :first {...}
>
> BEGIN :priority(5) {...}
That's why we pay you, Luke -- to keep up with the syntax. :-)
(Actually, Outlook seems to have transmogrified my guillemets into angle brackets. I
find that quite frustrating -- I think I'd rather have them appear to everyone else as
Korean spam than as incorrect ascii. So much for Office ServicePack 3...)
> I trust that these pairs will be somehow moved into their pair position
> after the block by Perl, since named args have to come after positional
> args. There are a lot of functions that take blocks, and writing:
>
> BEGIN {
> print "I am here: [ ";
> print(
> @data ==> map { .join(',') }
> ==> join ';');
> print " ]\n";
> } :first;
>
> Seems to horribly violate end weight.
Ayup.
> > package SomePackage;
> > BEGIN will go <after OtherPackage::BEGIN> {
> > print "Second!";
> > }
> >
> > END will go <priority 5> {
> > print "End block with early priority";
> > }
> >
> > package ThirdPackage;
> > END will go <group BEGIN before SomePackage::BEGIN> {
> > print "I feel really out of place!";
> > }
> >
> > Comment?
>
> As far as the execution groups, no, I don't think so. In particular,
> because I want:
>
> use SomePackage;
> BEGIN {
> SomePackage::foo();
> }
>
> to work without doing some unnecessarily verbose encantation on that
> BEGIN.
Who says you need verbosity? The default behavior will dwym, natch. The execution
grouping and prioritization and other stuff, which those-who-live-in-compiler-land
understand better than I ever hope to, are where the verbosity goes.
If you want "after p6 reads the end of file but before the final reduction", well,
there's an execution group for that. And if you want "after the reduction but before
peephole optimization", you're in luck. And if you want "I'm not sure when, but it
should be just before the BEGIN block from this other module", we can do that, too.
And there's not an entire page of uppercase names that I have to thumbtack to my
cubicle wall, since I can never remember this crap. Instead, we stay with BEGIN and
END for compiler-phase stuff, and then immediately switch to "better" ways of thinking
about this stuff, like "at object instantiation", "at destruction", which are actually
data-related.
> On the other hand, using a flag to indicate that you want a particular
> END to be [one of] the very last may be the right way to go. It's
> uncommon enough that the people who need it will be more than willing to
> look it up.
My thought, exactly.
> Luke
=Austin
