On Fri, Mar 05, 2004 at 01:57:40PM -0000, Rafael Garcia-Suarez wrote:
: While we're at it. Is there some precise definition of the CHECK/INIT
: blocks for perl 6 right now ?
Yes, the same precise definition as anything else we haven't defined yet:
"That works exactly the same as in Perl 5, until we change our minds." :-)
: In perl 5 those blocks are executed at the
: transition between the compilation and the execution phase *of the main
: program*. This is convenient for some purposes (the O and B::* modules)
: and inconvient for others (Attribute::Handlers, etc. etc.).
Hmm, well, I think it's a problem with Attribute::Handlers only because
that interface binds too late by default. Perl 6 traits will run at
BEGIN time by default. (Though you can define actions at trait time
that don't run till a later phase.) Can you elaborate on the etc. etc.?
: It's not
: feasible to modify this for Backwards Compatibility Reasons; how will
: Perl 6 handle this ? is there going to be a CHECK-by-compilation-unit
: kind of block ?
The "link" phase is still controlled by the main compilation pulling
in other modules, so CHECK still has the same semantics for the main
program, at least. And for consistency (especially with Perl 5),
a CHECK block from a separately compiled module probably should wait
till end of "link" time to run. Particularly since we have modules
that specifically create a CHECK knowing it runs at the end of the
main compilation.
So if we divide the CHECK notion up, you are correct that it's the
end-of-the-compilation-unit check that needs a new name. That might
be convenient, though redundant, since you can always run something at
the end of the compilation by putting a BEGIN block down at the bottom.
That BEGIN wouldn't know that it's the last thing, and can't guarantee
that it's the last thing if someone inserts more code after it, but
that doesn't stop you from putting stuff into the BEGIN block that
knows it's the last thing, and putting a comment afterwards saying
# Put no code here. Put it before the preceding BEGIN
On the other hand, there are things that the compiler probably has
to think about at the end of the compilation unit, and you might want
to do something after that. For example, given the way that subs
can forward-ref a declaration they haven't seen yet, we might want
to figure out at that time what signature to apply to a mysterious
call like:
foo(@bar, @baz)
So your final BEGIN would be ignorant of that decision unless it had
some way to force it. But if we're going to provide an interface to
let BEGIN tell the compiler to finish up, that's just as complicated
as providing a different kind of block that lets the compiler finish
up explicitly.
So I guess the question boils down to, what shall we name it?
UNBEGIN
POSTCOMP
PRELINK
COMPCHECK
UNITCHECK
Actually, I could see an argument for REDUCE, which runs after the
current block is reduced in the grammar. Which, if put at file-scope
level, comes out to running after the file is reduced, kinda sorta,
though to get the right semantics we'd have to consider not just the
grammatical reduction, but all the action routines triggered as part
of the reduction.
So that might also give us a way to capture control after a sub is
compiled, for instance. Or at least, its closure block... Hmm.
BEGIN blocks work fine for that, probably better, since the reduction
of the entire sub can happen, not just the block associated with
the sub. So nevermind about REDUCE. It seems to be an ill-formed
notion, since multiple reductions happen before your entire sub is
defined.
Which takes us back to something like UNITCHECK. Let's see:
my @x will unitcheck { .stuff() };
I guess that works as a verb.
So unless someone talks me out of it, we now have
my @x will begin {...} # at BEGIN time
my @x will unitcheck {...} # at UNITCHECK time
my @x will check {...} # at CHECK time
my @x will init {...} # at INIT time
my @x will pre {...} # at PRE time (return boolean for DBC)
my @x will enter {...} # at ENTER time (block entry)
my @x will leave {...} # at LEAVE time (block exit)
my @x will post {...} # at POST time (return boolean for DBC)
my @x will end {...} # at END time
state @x will first {...} # at FIRST time (first time through)
has @.x will build {...} # at BUILD time (object init time)
But most of you don't officially know about that last one yet.
Few more days... :-)
Larry
