On Mon, Mar 08, 2004 at 11:57:04PM +0000, 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 INIT time
: > my @x will end {...} # at END time
:
: Sorry, perhaps I wasn't paying close enough attention, but suddenly we've
: leaped from oddly named subs that get called at interesting times, to
: array variables with oddly-named properties (or attributes, or whatever).
: Je ne comprend pas :-(.
Oddly named subs are cool as such, but there are times when you
don't so much want an oddly named sub as an oddly named method.
These are just oddly named methods on the container in question
(which certainly doesn't have to be an array). Underneath they're
still oddly named subs in terms of when they run. But they implicitly
get (as their first argument/invocant/topic) the container in question,
so they can do fancy things with $_ and .foo and C<when> and such.
The "will first" syntax is mentioned in A6. Plus we discussed it
last April with respect to "state" variables--see message below.
Larry
>From [EMAIL PROTECTED] Tue Apr 15 11:56:23 2003
Date: Tue, 15 Apr 2003 11:19:42 -0700
From: Larry Wall <[EMAIL PROTECTED]>
Subject: Re: Initializations outside of control flow
To: [EMAIL PROTECTED]
On Tue, Apr 15, 2003 at 10:34:35AM -0400, Mark J. Reed wrote:
: It just seems like there should be a way to accomplish that without
: the visual clutter. Perhaps a trait:
:
: my $count is initially($INITIAL_VALUE);
:
: If there's already a defined way of doing that in Perl 6, please
: point me at it and I'll go away chastened but happy. Otherwise,
: does this seem a reasonable approach? Ideas for a better name for
: the trait?
The traits in question are already named corresponding to the
various initialization closures, which at the moment are named
BEGIN {...}
CHECK {...}
INIT {...}
FIRST {...}
ENTER {...}
so, since the variable in question is the topic of the closure, we have
my $count will begin { .set($INITIAL_VALUE) }
my $count will check { .set($INITIAL_VALUE) }
my $count will init { .set($INITIAL_VALUE) }
my $count will first { .set($INITIAL_VALUE) }
my $count will enter { .set($INITIAL_VALUE) }
Perhaps those particular traits are smart enough to distinguish whether
they have a closure or not, and build an appropriate closure if not,
so we could also have
my $count is begin($INITIAL_VALUE)
my $count is check($INITIAL_VALUE)
my $count is init($INITIAL_VALUE)
my $count is first($INITIAL_VALUE)
my $count is enter($INITIAL_VALUE)
At the moment, I believe that = always happens at run-time. So
my $count = BEGIN { calculation() }
would do the calculation at compile time but assign the resulting
value every time the statement is executed. This means that a
declaration like:
state $where = $x;
is almost certainly incorrect. It should probably be one of
state $where is begin($x);
state $where is check($x);
state $where is init($x);
state $where is first($x);
Could go so far as to lose the "is", treating these as variants of
"is".
state $where begin($x);
state $where check($x);
state $where init($x);
state $where first($x);
The other possible approach would be to allow blockless closures like
BEGIN (state $where = $x);
CHECK (state $where = $x);
INIT (state $where = $x);
FIRST (state $where = $x);
Maybe the parens aren't necessary, if they just introduce a syntactic
statement:
BEGIN state $where = $x;
CHECK state $where = $x;
INIT state $where = $x;
FIRST state $where = $x;
But I think it would be a mistake to have = running at random times
depending on either the "foo" and "BAR" in
foo $x = BAR { ... }
Larry
