Compile-time undefined sub detection
Nigel Sandever
at compile time?
Regards, Nigel.
Larry Wall
: On the basis of what is known so far, will p6 be able to detect
: undefined subs at compile time?
In theory, yes, if you ask it to check in a CHECK block, and if you're
willing for the check to assume that no eval or INIT block is going
to supply the missing sub before it's actually called, and that no
run-time code is going to alias the sub into one of your namespaces
where it'll be visible to call, and that no AUTOLOAD in scope will
be willing to emulate it. (But then, all that's true of Perl 5 right
now as well...)
Larry
Rafael Garcia-Suarez
>
> In theory, yes, if you ask it to check in a CHECK block, and if you're
> willing for the check to assume that no eval or INIT block is going
> to supply the missing sub before it's actually called, and that no
> run-time code is going to alias the sub into one of your namespaces
> where it'll be visible to call, and that no AUTOLOAD in scope will
> be willing to emulate it. (But then, all that's true of Perl 5 right
> now as well...)
While we're at it. Is there some precise definition of the CHECK/INIT
blocks for perl 6 right now ? 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.). 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 ?
Larry Wall
: 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
Rafael Garcia-Suarez
>: 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.?
Of course :) the main problem is not that CHECK blocks are executed
late (just at the end of the compilation phase); it's that they're
executed too early, notably in some persistent environment, notably
mod_perl (or mod_parrot in the future.) When you have a virtual machine,
you'll end up including modules at run time, because the main
compilation phase becomes less important. Thus CHECK blocks become
worthless, code-reusability-wise.
> 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.
But, as I was saying, modules have no control on what the end of the
compilation is; notably, they've no control on whether it's still
finished.
> my @x will unitcheck {...} # at UNITCHECK time
"your next mission is now to put something like this in Perl 5..."
Larry Wall
: Of course :) the main problem is not that CHECK blocks are executed
: late (just at the end of the compilation phase); it's that they're
: executed too early, notably in some persistent environment, notably
: mod_perl (or mod_parrot in the future.) When you have a virtual machine,
: you'll end up including modules at run time, because the main
: compilation phase becomes less important. Thus CHECK blocks become
: worthless, code-reusability-wise.
Possibly a CHECK block that is compiled after end of main compilation
should translate itself to a UNITCHECK. But maybe it should be an error.
But it's also possible that CHECK should mean "unit check", and
there should be an explicit MAINCHECK for delegating checks to the
main compilation. In that case, only in the main compilation would
CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is
explicitly requesting a check at the end of main, a late MAINCHECK
should probably be considered an error. (But by that argument, a late
CHECK should probably fail under the current naming scheme.))
Anybody got opinions on the naming of these beasts? Certainly *not*
renaming CHECK is more compatible with Perl 5. And I kinda got fond
of UNITCHECK in the last hour or so. :-)
Larry
Rafael Garcia-Suarez
>
> should translate itself to a UNITCHECK. But maybe it should be an error.
>
> But it's also possible that CHECK should mean "unit check", and
> there should be an explicit MAINCHECK for delegating checks to the
> main compilation. In that case, only in the main compilation would
> CHECK and MAINCHECK mean the same thing. (And since MAINCHECK is
> explicitly requesting a check at the end of main, a late MAINCHECK
> should probably be considered an error. (But by that argument, a late
> CHECK should probably fail under the current naming scheme.))
>
> Anybody got opinions on the naming of these beasts? Certainly *not*
> renaming CHECK is more compatible with Perl 5. And I kinda got fond
> of UNITCHECK in the last hour or so. :-)
I think I like CHECK and MAINCHECK. (and MAINCHECK being an error
after the main compilation phase.)
Lots of people who use CHECK (for some value of "lots" -- let's say,
Damian and a few others) actually mean UNITCHECK. MAINCHECK is mainly
useful for the O compiler backend, which is part of the perl core
anyway, thus without any backward-compatility constraint. (I'd like to
have opinions about PAR as well.) So I think changing the meaning of
CHECK in Perl 5 is feasible. (and I know it would be welcomed by the
mod_perl crowd.)
Damian Conway
> Anybody got opinions on the naming of these beasts? Certainly *not*
> renaming CHECK is more compatible with Perl 5.
I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
Perl 5 and with software engineering jargon.
And because MAINCHECK is *ugly*. ;-)
So ugly that, if we go the other way and do change CHECK's behaviour, then the
new postlinkage phase should be something else: like POSTLINK or PREINIT or
INTEGRATE.
> And I kinda got fond of UNITCHECK in the last hour or so. :-)
Well, that counts in its favour too. ;-)
Does that imply a UNITEND as well?
Damian
Larry Wall
: Does that imply a UNITEND as well?
Why would you want to unite North Dakota?
And how would it differ from END? You can't predict when the last
time a module is going to get used...
Larry
Rod Adams
Given the fact that use of these blocks are overall quite rare, and
potentially very confusing to the casual perl hacker who encounters one
of them, I propose a rather different tact:
BEGIN => EXECUTE_ON_PARSE
CHECK => EXECUTE_AFTER_COMPILE and EXECUTE_AFTER_UNIT_COMPILE
INIT => EXECUTE_INITIALIZATION
END => EXECUTE_ON_EXIT
This also has the advantage of being able to reserve all subs with name
EXECUTE_.* for compiler/interpreter special sub like these, so we could
add more of them come perl 6.8 w/o much issue.
-- Rod
Rafael Garcia-Suarez
>
> I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
> Perl 5 and with software engineering jargon.
As far as Perl 5 is concerned, it appears that most people who write
CHECK mean UNITCHECK. Including you :)
> And because MAINCHECK is *ugly*. ;-)
I can't disagree.
> So ugly that, if we go the other way and do change CHECK's behaviour, then the
> new postlinkage phase should be something else: like POSTLINK or PREINIT or
> INTEGRATE.
But INTEGRATE is even more ugly.
Damian Conway
> And how would it differ from END?
Like CHECKs, ENDs execute in reverse order. Which generally means that main
END executes before module ENDs (unless we're careful to put our main END
before our module loads -- which is subtle and counterintuitive). Sometimes it
would be handy to be able to mark some cleanup code so that it executes before
main's END, regardless of how early main's END is declared.
> You can't predict when the last time a module is going to get used...
I'm not suggesting you need to. I'm saying that, just as all UNITCHECKs are
guaranteed to run before any main CHECK, we might want a UNITEND that's
guaranteed to execute before any main END.
Damian
Jonathan Scott Duff
> Given the fact that use of these blocks are overall quite rare, and
> potentially very confusing to the casual perl hacker who encounters one
> of them, I propose a rather different tact:
>
> BEGIN => EXECUTE_ON_PARSE
> CHECK => EXECUTE_AFTER_COMPILE and EXECUTE_AFTER_UNIT_COMPILE
> INIT => EXECUTE_INITIALIZATION
> END => EXECUTE_ON_EXIT
>
> This also has the advantage of being able to reserve all subs with name
> EXECUTE_.* for compiler/interpreter special sub like these, so we could
> add more of them come perl 6.8 w/o much issue.
I'm not sure I agree with your actual proposal, but I certainly agree
with the spirit of it. When I first saw UNITEND I had to double take
to make sure I read it correctly. I propose that if we use multi-word
block names, that they have an underscore between the words to be
slightly more readable. (I hate underscores, but I hate LONGCAPSWORDS
more)
-Scott
--
Jonathan Scott Duff Division of Nearshore Research
du...@lighthouse.tamucc.edu Senior Systems Analyst II
Austin Hastings
>
> I'm not suggesting you need to. I'm saying that, just as all
> UNITCHECKs are
> guaranteed to run before any main CHECK, we might want a UNITEND that's
> guaranteed to execute before any main END.
Perhaps this is one of those places where properties can help. Instead of
having BEFORE, REALLY_BEFORE, NO_I_MEAN_REALLY_BEFORE, DONE, MOSTLY_DONE,
PARTIALLY_DONE, WELL_DONE, DONE_AND_PROCESS_SPACE_ALMOST_RECLAIMED, etc., we
could simply use some ordering properties:
# 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.
#
# However, blocks in the same source file are guaranteed to run in order of
# occurrence. (Since they're catenated, basically.)
#
# 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!";
}
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?
=Austin
Luke Palmer
> Perhaps this is one of those places where properties can help. Instead of
> having BEFORE, REALLY_BEFORE, NO_I_MEAN_REALLY_BEFORE, DONE, MOSTLY_DONE,
> PARTIALLY_DONE, WELL_DONE, DONE_AND_PROCESS_SPACE_ALMOST_RECLAIMED, etc., we
> could simply use some ordering properties:
>
> # 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].
If I'm printing debug messages during compilation, say:
BEGIN {
print "Before load\n";
}
use SomePackage;
BEGIN {
print "After load\n";
}
I don't want to be getting:
BefAfter load
ore load
Obviously this is a pathological case, due to the restriction
immediately below, but you can extrapolate to more complex things.
> # However, blocks in the same source file are guaranteed to run in order of
> # occurrence. (Since they're catenated, basically.)
> #
> # 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) {...}
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.
> 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.
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.
Luke
[1] And that's really just to make those happy who are efficiency-crazy.
I have a strong aversion to automatic threading, and I don't care if it
takes more than one line to put it in. In any case, I want control of
my threads, otherwise my sweatshirt's going to come out raveled.
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:lu...@luqui.org]
> 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
Dan Sugalski
>Larry wrote:
>
>>Anybody got opinions on the naming of these beasts? Certainly *not*
>>renaming CHECK is more compatible with Perl 5.
>
>I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
>Perl 5 and with software engineering jargon.
How 'bout we make these properties on the subs instead of custom sub
names? There are some times when its useful to have a sub callable by
name as well as at a specified time in the startup sequence. (Which
is what parrot'll be doing *anyway*--BEGIN blocks will be subs with
bogus names with the :begin property on them, or something like that)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
James Mastros
> And how would it differ from END? You can't predict when the last
> time a module is going to get used...
Unless we support an explicit unload action on modules. This seems
highly useful for long-running processes. (I don't think making them
DODable is useful, since there's no way to tell if a future eval STRING
(or equiv) might be useful.)
-=- James Mastros
Larry Wall
Then the explicit unload can call an explicit routine in the module
for cleanup, I suspect. We don't really need a special name for it
in the language, except perhaps to set something up by convention.
We might not even need that if we require an unloadable module to
register its unloadability, in which case the module can pass a closure
to be called back at unload time.
Larry
Larry Wall
Okay, to be perfectly fair, that registration might then look exactly
like a funny block:
UNLOAD {...}
Larry
Dan Sugalski
>On Sat, Mar 13, 2004 at 08:39:02PM +0100, James Mastros wrote:
>: Larry Wall wrote:
>: >And how would it differ from END? You can't predict when the last
>: >time a module is going to get used...
>:
>: Unless we support an explicit unload action on modules. This seems
>: highly useful for long-running processes. (I don't think making them
>: DODable is useful, since there's no way to tell if a future eval STRING
>: (or equiv) might be useful.)
>
>Then the explicit unload can call an explicit routine in the module
>for cleanup, I suspect.
That's going to be the only way to reasonably unload a module, and
even then there'll be some interesting repercussions. Like... what
happens when you unload a module with instantiated objects? How can
you tell if there are secondary modules that need unloading? Does
unloading actually unload, or just remove as many links to the module
as we can and we then unload it when the last real reference to it
goes away? Can we *re*load a module that's been unloaded? (The answer
to that last one's no, for some modules that load in external
libraries)
It's an interesting problem. Modules leave debris around which can
make it difficult to properly deal with, and allowing them to be
unloaded requires a fair amount of thought.
Larry Wall
: That's going to be the only way to reasonably unload a module, and
: happens when you unload a module with instantiated objects? How can
: you tell if there are secondary modules that need unloading? Does
: unloading actually unload, or just remove as many links to the module
: as we can and we then unload it when the last real reference to it
: goes away? Can we *re*load a module that's been unloaded? (The answer
: to that last one's no, for some modules that load in external
: libraries)
:
: It's an interesting problem. Modules leave debris around which can
: make it difficult to properly deal with, and allowing them to be
: unloaded requires a fair amount of thought.
Which is all good reason to assume a module is not unloadable unless
it declares its intent to be unloadable--and then it's just on a
"best effort" basis.
"Best effort" is one of those phrases that doesn't mean what it means...
Larry