On Mon, Mar 15, 2004 at 04:22:27PM -0500, Dan Sugalski wrote:
: 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 se
At 12:30 PM -0800 3/15/04, Larry Wall wrote:
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.
On Mon, Mar 15, 2004 at 12:30:51PM -0800, Larry Wall wrote:
: 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 explici
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-runnin
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
- Original Message -
From: "Larry Wall" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 06, 2004 10:39 PM
Subject: Re: Magic blocks (was: Compile-time undefined sub detection)
> Oh, I accidentally left NEXT out of my canonical list.
On Mon, Mar 08, 2004 at 11:57:04PM +, Dave Mitchell wrote:
: On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
: > my @x will begin {...} # at BEGIN time
: > my @x will check {...} # at CHECK time (redefined to unit check)
: > my @x will init {...} # at INI
On Sat, Mar 06, 2004 at 06:39:44PM -0800, Larry Wall wrote:
> my @x will begin {...} # at BEGIN time
> my @x will check {...} # at CHECK time (redefined to unit check)
> my @x will init {...} # at INIT time
> my @x will end {...}# at END time
Sorry, perhaps
At 8:47 AM +1100 3/6/04, Damian Conway wrote:
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
Oh, I accidentally left NEXT out of my canonical list. We do need to
have the equivalent to Perl 5's "continue".
Larry
Okay you guys, you're running away from one kind of madness and
proposing various other kinds of madness in its place. Mostly you're
confusing what should be easy and what should be possible.
First a note about cleanup dependencies. In general, these should be
driven by the structure of the data
> -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 paral
Austin Hastings writes:
> 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:
> > 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
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
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
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 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
:
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 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
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
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 :
>: 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 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 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 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
On the basis of what is known so far, will p6 be able to detect undefined subs
at compile time?
Regards, Nigel.
27 matches
Mail list logo
