On the basis of what is known so far, will p6 be able to detect undefined subs
at compile time?
Regards, Nigel.
On Thu, Mar 04, 2004 at 11:04:38PM +, Nigel Sandever wrote:
: 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
Larry Wall wrote in perl.perl6.language :
>
> 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
On Fri, Mar 05, 2004 at 01:57:40PM -, 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 w
Larry Wall wrote in perl.perl6.language :
>: 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.)
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote:
: 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_p
Larry Wall wrote in perl.perl6.language :
>
> 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 MAINCHE
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.
And because MAINCHECK is *ugly*. ;-)
So ugly th
On Sat, Mar 06, 2004 at 08:47:25AM +1100, Damian Conway wrote:
: 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
Larry Wall wrote:
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote:
: 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
:
Damian Conway wrote in perl.perl6.language :
>
> 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 MAIN
Larry asked:
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
On Fri, Mar 05, 2004 at 04:17:12PM -0600, Rod Adams wrote:
> 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 => EXECUT
> > 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.
Perhaps this is one of
14 matches
Mail list logo
