Re: Does this mean we get Ruby/CLU-style iterators?

[Michael G Schwern]

On Fri, Jan 18, 2002 at 08:03:41PM -0800, Larry Wall wrote:
> : allow this:
> : 
> : File.foreach('/usr/dict/words') { print }
> 
> File.foreach('/usr/dict/words', { print })
> 
> or even (presuming the prototype is available for parsing):
> 
> File.foreach '/usr/dict/words' { print }

Now I'm a little confused.  The apoc talked about writing your own
while loop.  A while loop looks like:

while($something) { do_this }

and a custom while loop would have to be

mywhile($something) { do_this }

and it doesn't seem much of a stretch for

Class.method($something) { do_this }

or is that what you ment by "ignoring parser issues"?


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
Death was thought to be fatal.
-- Craig A. Berry in 

Apoc4 - A little wish

[Angel Faus]

Hi all,

I have just one syntatic wish for Apoc4 (which in all other points I 
find utterly fantastic).

Could we have:

 foreach $item in @arr {...}

Instead of

 foreach @arr -> $item {...}

I find the first one:

- Much more pleasent to the eyes and less noisy on a long program.
- Easier for the newcomer to get the meaning.
- More similar to perl5's  foreach $item (@arr), since at least we 
preserve the order.

The multi-array foreaching could become:

 foreach $item; $other in @arr; @otherarr {...} # as in Apoc4

Or maybe

 foreach $item in @arr; $other in @otherarr {...}

On a totally different level of foreaching:

¿are we going to have a iterator protocol? I am talking of python's 
iterators, not ruby ones (which are being discussed in a different 
post). The iterator protocol allows any object that implements a .next 
method to be used in a foreach loop. This is very handy for things like 
filehandles, recordsets, generators, coroutines and nearly any data 
structure you can imagine.

For example, filehandles can implent the iterator protocol out of the 
box, so you can write:

 foreach $line in $fh {print $line}

Or maybe:

 foreach $line in $fh.lines {print $line}

Where $fh.lines is an object that implements the iterator protocol, not 
an array of the lines (and thus much more efficient).

There was something about this in Apoc2, but I didn't get a clear 
concolusion of it. The are a lot of useful applications of python-like 
iterators, and perl6 is doing a great job of taking the coolest things 
of other languages and integrating them into a choerent design, so i do 
have a hope. [:)]

This is of course related to Ruby's iterators, that take a somehow 
opposite solution to solve a similar problem.

-
Angel Faus
[EMAIL PROTECTED] 

Re: Apoc4 - A little wish

[Angel Faus]

Sorry for the 4 times posts, i was testing a new mail program and it 
didn't prove too good.

Now i feel so ashamed :-[

-angel

Re: Apoc4 - A little wish

[Randal L. Schwartz]

> "Angel" == Angel Faus <[EMAIL PROTECTED]> writes:

Angel> Hi all,
Angel> I have just one syntatic wish for Apoc4 (which in all other points I
Angel> find utterly fantastic).

Angel> Could we have:

Angel>  foreach $item in @arr {...}

Angel> Instead of

Angel>  foreach @arr -> $item {...}

Larry considered that, and declined.  Not sure of the reasons.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Apoc4: "When do I put a semicolon after a curly?"

[Bryan C. Warnock]

The two current examples of an evil expression block are do {} and eval {}, 
which require a semicolon terminator.  However, with eval {} leaving, that 
leaves just do {}, which does (or should) fall more in line of thinking of 
grep {}, map {}, and sort {}: the other expression blocks.  For do {}, the 
block just happens to be the only (and therefore, trailing) argument.  (In 
other words, from an language perspective, do {} really should be presented 
more as 'do' and less as '{}'.  Much of the block confusion came from the 
specialization  of do-while and do-until.  But both of these are illegal in 
Perl 6, so there's no longer a reason to propagate that misconception.)

With try {} appearing to be a proper block, that would leave do {} the only 
beneficiary of the Lone Bracket hack.  (For now.  I continue this below.)
So, in essence, you are trading "you need to remember that do {} is just an 
expression, treat is as such" to "do {} is an expression.  You can write it 
as a block (as long as the close bracket is on a line by itself), and we'll 
tack on the semicolon for you, but don't write it as a block when you want 
an expression, unless you put the rest of the expression on the same line as 
the bracket."  Although each individual rule is simple, the overall 
semantics have become quite complex for such a small subsection of the 
language.  And attempting to leverage that against a lone bracket, I feel is 
a mistake.  From a linguistical perspective, that seems to be more 
presentationally based, rather than contextual.  

Most everything in Perl is done in context, so why not leverage that 
instead?  After all, the semi-colon will be needed to terminate an anonymous 
hash assignment, yes?

my $ahash = {
foo => bar
};

It seems to me that when people use a block as a code block, they simply 
don't make it do expressionish things.  Like capture the return 
value.  Blocks are almost always - there are always Damians in the world - 
used in a void context.

my $a = do { 

}

No, it's not a block, it's an expression.  It shouldn't even be presented as 
a potential block.  You've a do {} in the midst of a long string of things,
it shouldn't terminate simply because I'm formatting for clarity.

do {
...
}

could be a block.  Particularly now that base blocks are forbidden, this 
will be a block.  The question is whether the expression continues 
afterwords:

+ 1 for @x;

The parser should be able to determine whether the expression continues
on the next line.  You either get an operator or a statement modifier, or 
the block is terminated.  But for the user who has to remember all the rules,
there's nothing to do.  He just writes it.  Contextual.  Not presentational. 
 
The Apo surmises that some other blocks may become expression blocks,
such as BEGIN {}.  I assume CHECK {} and INIT {}, as well?  END {} doesn't 
make sense.  How about any of the new blocks?

Now, you've added even more special cases to the semi-colon rule.:

BEGIN { foo() };
END { foo() }

Some will take them - sometimes - and others won't, at all.  Sure, you could 
always put a semicolon there, and create a null statement, but you don't do 
that now, so why should you start?

Once again, I think the void contextual clues should be differentiating 
between block and expression usage.  Perl already exprects you to understand 
differing behavior in void, scalar, and list context, and Perl 6 is expected 
to add more.  Why not continue in that direction here, instead of veering 
off in some strange direction.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Apoc4: Parentheses

[Bryan C. Warnock]

Interestingly, this one tweak to the whitespace rule also means that we'll 
be able to simplify the parentheses out of other similar built-in constructs:

if $foo { ... }
elsif $bar { ... }
else { ... }

while $more { ... }

for 1..10 { ... }

I think throwing out two required punctuation characters for one required 
whitespace is an excellent trade in terms of readability, particularly when 
it already matches common practice. (You can still put in the parens if you 
want them, of course, just for old times' sake.)


Since the parentheses are no longer required, will the expressions lose or 
retain their own scope level?  (I'm assuming that whatever rule applies, it 
will hold true if you do elect to use parantheses anyway.)


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Benchmarking regexps against perl5

[Chris Ball]

On Fri, Jan 18, 2002 at 11:45:37PM +, Nicholas Clark wrote:
> How hard is it to "knobble" a perl5 to disable the regular expression
> optimiser?

Should be trivial.  S_study_chunk(), regcomp.c:676.

> And then later perl5 be allowed its optimiser back once parrot has one.

Did you mean 'one', or 'won'?  :-)

- Chris.
--
$a="printf.net"; Chris Ball | chris@void.$a | www.$a | finger: chris@$a
As to luck, there's the old miners' proverb: Gold is where you find it.

Apoc4: The loop keyword

[Bryan C. Warnock]

No examples are given, but are we to assume that this:

for ($x = 0; $x < 100; $x++) {
...
}

becomes this:

loop $x=0; $x < 100; $x++ {
...
}

How would you use an $x lexically scoped to the loop block?
Most of the other constructs seem to be using a '-> $x' construct.

loop my $x=0; $x < 100; $x++ {
...
}

?

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Apoc4: 'when' blocks versus statements

[Bryan C. Warnock]

Why the double semantics of 'when'?

It implicitly breaks when used as a 'when' block, but does not as a 'when' 
statement.  It seems that a when should be a when should be a when, and a 
when being a when would be a win.  

The example given:

 given $x {
warn("Odd value")when !/xxx/;
warn("No value"), break  when undef;

when /aaa/ { break when 1; ... }
when /bbb/ { break when 2; ... }
when /ccc/ { break when 3; ... }
}

could be written as:

 given $x {
warn("Odd value"), skip  when !/xxx/;
warn("No value") when undef;

when /aaa/ { break when 1; ... }# No reason you can't
when /bbb/ { break when 2; ... }# explicitly break even when
when /ccc/ { break when 3; ... }# you'd implicitly
}

or even:

 given $x {
warn("Odd value")  if   !/xxx/;  # Since $_ is the localizer
warn("No value")   when  undef;

when /aaa/ { break if 1; ... }
when /bbb/ { break if 2; ... }
when /ccc/ { break if 3; ... }
}


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Apoc 4?

[Bart Lateur]

On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote:

>http://www.perl.com/pub/a/2002/01/15/apo4.html
>
>David Whipp wrote:
>> 
>> Michael G Schwern wrote:
>> 
>> > Reading this in Apoc 4 ...
>> 
>> I looked on http://dev.perl.org/perl6/apocalypse/: no sign of Apoc4. Where
>> do I find this latest installment?

I thought I had just missed it... but there's no trace of it in the
archives of <[EMAIL PROTECTED]>. Or any other perl6 list.

Don't tell me that is normal.

-- 
Bart.

Re: on parrot strings

[Jarkko Hietaniemi]

Honour where honour is due: I've got some questions about inversion
lists.  Where I saw them mentioned by that name were some drafts of
this:

http://www.aw.com/catalog/academic/product/1,4096,0201700522,00.html

The book looks really promising-- unfortunately it's not yet published.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Apoc4: "When do I put a semicolon after a curly?"

[Piers Cawley]

You're treating do, if, foreach as if they were keywords. I'm not
entirely sure that that's still the case. And you're also forgetting
the possibility of user implemented control type operators/methods.

Unless I'm very much mistaken you're suggesting that we special case
the parser for 'do' and any user defined functions that take a block
can go hang. Which I'm really not keen on.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: cvs commit: parrot pbc2c.pl

[Melvin Smith]

>   Stop this stupid "hard-code the new oplib" stuff.

Doh - I saw this last night but was too lazy to fix it...  :)

-Melvin

Re: Apoc4: "When do I put a semicolon after a curly?"

[Bryan C. Warnock]

On Saturday 19 January 2002 12:24, Piers Cawley wrote:
> You're treating do, if, foreach as if they were keywords. I'm not
> entirely sure that that's still the case. 

'do' perhaps.  But not really.  And it's irrelevant to my argument.

> And you're also forgetting
> the possibility of user implemented control type operators/methods.

No, I'm not.  As a matter of fact, I had even wrote a section on 
user-defined constructs, only to find that my arguments were exactly the 
same, so I removed it as superfluous.

>
> Unless I'm very much mistaken you're suggesting that we special case
> the parser for 'do' and any user defined functions that take a block
> can go hang. Which I'm really not keen on.

Then you're very much mistaken.  :-)

I'm saying that if you're going to DWIM an expression as a block, do it 
based on the expression being used in the standard context of a block, 
rather than the fact that the trailing '}' appears on a line by itself.  In 
other words, I'm very much for Larry's idea.  Just put the burden on the 
parser, rather than on the parser and the person.
 
That applies to *any* expressionish block - do, BEGIN, INIT, sub (sort of), 
the old eval which is now gone, or a user-defined one.  I simply picked on 
do {} and BEGIN {} because they were the examples given in the Apocalypse.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Apoc 4?

[iain truskett]

* Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]:
> On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote:
> > http://www.perl.com/pub/a/2002/01/15/apo4.html
[...]
> I thought I had just missed it... but there's no trace of it in the
> archives of <[EMAIL PROTECTED]>. Or any other perl6 list.

> Don't tell me that is normal.

It's a worry. Also odd is that Slashdot hasn't picked it up yet.

I don't know about most people, but I saw the announcement on
http://use.perl.org/


cheers,
-- 
iain.  

Re: Apoc 4?

[Bryan C. Warnock]

On Saturday 19 January 2002 12:20, iain truskett wrote:
> * Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]:
> > On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote:
> > > http://www.perl.com/pub/a/2002/01/15/apo4.html
>
> [...]
>
> > I thought I had just missed it... but there's no trace of it in the
> > archives of <[EMAIL PROTECTED]>. Or any other perl6 list.
> >
> > Don't tell me that is normal.
>
> It's a worry. Also odd is that Slashdot hasn't picked it up yet.

Developers' section.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

[PATCH] Core.ops documentation clean up

[Simon Glover]

 Enclosed patch attempts to resynchronize the core.ops documentation 
 with the actual code. It also fixes a few typos and overlong lines.

 Simon

--- core.ops.oldSat Jan 19 16:36:59 2002
+++ core.opsSat Jan 19 18:19:36 2002
@@ -218,8 +218,13 @@
 
 =item B(in INT, in NUM)
 
+=item B(in INT, in STR)
+
 =item B(in INT, in PMC)
 
+Print $2 to the file on $1. (0, 1, and 2 correspond to stdin, stdout,
+and stderr)
+
 =cut
 
 inline op print(in INT) {
@@ -488,19 +493,13 @@
 
 Set $1 to $2.
 
-=item B(out INT, in PMC, in INT)
-
-=item B(out NUM, in PMC, in INT)
-
-=item B(out STR, in PMC, in INT)
-
 =item B(out PMC, in INT, in INT)
 
 =item B(out PMC, in NUM, in INT)
 
 =item B(out PMC, in STR, in INT)
 
-Set $1 to index $1 of array $2
+Set the value stored at index $3 of array $1 to $2.
 
 =item B(out INT, in PMC, in INT)
 
@@ -508,13 +507,23 @@
 
 =item B(out STR, in PMC, in INT)
 
-=item B(out PMC, in INT, in INT)
+Set $1 to the value stored at index $3 of array $2.
 
-=item B(out PMC, in NUM, in INT)
+=item B(out PMC, in INT, in STR)
 
-=item B(out PMC, in STR, in INT)
+=item B(out PMC, in NUM, in STR)
+
+=item B(out PMC, in STR, in STR)
+
+Set the value associated with key $3 of hash $1 to $2.
+
+=item B(out INT, in PMC, in STR)
 
-Set $1 to index $3 of hash $2
+=item B(out NUM, in PMC, in STR)
+
+=item B(out STR, in PMC, in STR)
+
+Set $1 to the value associated with key $3 of hash $2.
 
 =cut
 
@@ -643,7 +652,7 @@
 
 =head2 Conditional branch operations
 
-These opertions perform a conditional relative branch. If the condition is
+These operations perform a conditional relative branch. If the condition is
 met, the branch happens, otherwise control falls to the next operation.
 
 =over 4
@@ -783,8 +792,6 @@
 
 =item B(in NUM, in NUM, in INT)
 
-=item B(in PMC, in PMC, in INT)
-
 =item B(in STR, in STR, in INT)
 
 Branch if $1 is less than $2.
@@ -1321,8 +1328,6 @@
 
 =item B(out NUM, in NUM, in NUM)
 
-=item B(n, n, nc)
-
 Set $1 to the product of $2 and $3.
 
 =cut
@@ -1416,7 +1421,8 @@
 
 Remove $2 characters from the end of the string in $1.
 
-TODO: Create a three-argument version of this? Don't force in-place modification.
+TODO: Create a three-argument version of this? Don't force in-place 
+modification.
 
 =cut
 
@@ -1483,8 +1489,8 @@
 
 =item B(out STR, in STR, in INT, in INT)
 
-Set $1 to the portion of $2 starting at (zero-based) character position $3 and having
-length $4.
+Set $1 to the portion of $2 starting at (zero-based) character position $3 
+and having length $4.
 
 =cut
 
@@ -1675,7 +1681,8 @@
 
 =item B(out NUM, in NUM)
 
-Set $1 to I raised to the power $2. I is the base of the natural logarithm.
+Set $1 to I raised to the power $2. I is the base of the natural 
+logarithm.
 
 =cut
 
@@ -1901,7 +1908,8 @@
 
 =item B(out INT, in INT, in INT)
 
-Set the bits of $1 according to the B of the corresponding bits from $2 and $3.
+Set the bits of $1 according to the B of the corresponding bits from 
+$2 and $3.
 
 =cut
 
@@ -1929,7 +1937,8 @@
 
 =item B(out INT, in INT, in INT)
 
-Set the bits of $1 according to the B of the corresponding bits from $2 and $3.
+Set the bits of $1 according to the B of the corresponding bits from 
+$2 and $3.
 
 =cut
 
@@ -1970,7 +1979,8 @@
 
 =item B(out INT, in INT, in INT)
 
-Set the bits of $1 according to the B of the corresponding bits from $2 and $3.
+Set the bits of $1 according to the B of the corresponding bits from 
+$2 and $3.
 
 =cut
 
@@ -2065,7 +2075,7 @@
 
 =head2 Register operations
 
-These operations effect entire sets of registers.
+These operations affect entire sets of registers.
 
 =over 4
 
@@ -2224,7 +2234,7 @@
 
 =head2 Register stack operations
 
-These operations effect individual registers.
+These operations affect individual registers.
 
 =over 4
 
@@ -2235,7 +2245,7 @@
 
 =item B(out INT, in INT)
 
-Gets the type of entry $2 of the stack and puts in in $1
+Gets the type of entry $2 of the stack and puts it in $1
 
 =cut
 
@@ -2376,7 +2386,8 @@
 =cut
 
 inline op bsr (in INT) {
-  stack_push(interpreter, interpreter->control_stack, expr NEXT(),  
STACK_ENTRY_DESTINATION, NULL);
+  stack_push(interpreter, interpreter->control_stack, expr NEXT(),  
+ STACK_ENTRY_DESTINATION, NULL);
   goto OFFSET($1);
 }
 
@@ -2423,7 +2434,7 @@
 
 =item B(out PMC, in INT)
 
-Create a new interpreter and store it in a PMC
+Create a new interpreter and store it in a PMC.
 
 =cut
 
@@ -2441,7 +2452,7 @@
 
 =item B(inout PMC, in INT)
 
-Take a built interpreter and run the code starting at offset $2
+Take a built interpreter and run the code starting at offset $2.
 
 =cut
 
@@ -2495,7 +2506,7 @@
 
 =item B(in INT)
 
-Sleep for $1 seconds
+Sleep for $1 seconds.
 
 =cut
 
@@ -2512,7 +2523,7 @@
 
 =item B(in INT)
 
-Set the current line number we're executing code for
+Set the current line number we're executing code for.
 
 =cut
 
@@ -2523,7 +2534,7 @@
 
 =item B(out INT)
 
-Get the current line number
+Get the current line numb

Re: Apoc 4?

[Dan Sugalski]

At 1:14 PM -0500 1/19/02, Bryan C. Warnock wrote:
>On Saturday 19 January 2002 12:20, iain truskett wrote:
>>  * Bart Lateur ([EMAIL PROTECTED]) [20 Jan 2002 03:56]:
>>  > On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote:
>>  > > http://www.perl.com/pub/a/2002/01/15/apo4.html
>>
>>  [...]
>>
>>  > I thought I had just missed it... but there's no trace of it in the
>>  > archives of <[EMAIL PROTECTED]>. Or any other perl6 list.
>>  >
>>  > Don't tell me that is normal.
>>
>>  It's a worry. Also odd is that Slashdot hasn't picked it up yet.
>
>Developers' section.

No wonder nobody noticed. There seems to be an awful lot of actually 
interesting stuff over there. How atypically slashdot...
-- 

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: on parrot strings

[Graham Barr]

I belive IBM use inversion lists in thier ICU library for sets of
unicode characters.

Graham.

On Sat, Jan 19, 2002 at 07:08:25PM +0200, Jarkko Hietaniemi wrote:
> Honour where honour is due: I've got some questions about inversion
> lists.  Where I saw them mentioned by that name were some drafts of
> this:
> 
> http://www.aw.com/catalog/academic/product/1,4096,0201700522,00.html
> 
> The book looks really promising-- unfortunately it's not yet published.
> 
> -- 
> $jhi++; # http://www.iki.fi/jhi/
> # There is this special biologist word we use for 'stable'.
> # It is 'dead'. -- Jack Cohen

Re: on parrot strings

[Simon Cozens]

On Sat, Jan 19, 2002 at 07:08:25PM +0200, Jarkko Hietaniemi wrote:
> http://www.aw.com/catalog/academic/product/1,4096,0201700522,00.html
> The book looks really promising-- unfortunately it's not yet published.

Isn't this, uhm, http://www.concentric.net/~rtgillam/pubs/unibook/index.html ?

-- 
Sigh.  I like to think it's just the Linux people who want to be on
the "leading edge" so bad they walk right off the precipice.
(Craig E. Groeschel)

Perl 6, now with 50% more NATO!

[Michael G Schwern]

This just popped up from my sig file:

Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition.  The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in <[EMAIL PROTECTED]>

which, of course, we'll have in Perl 6:

loop {
.search && .DESTROY;
}

Larry Wall: puppet of the military-industrial complex?  Next on "The
Conspiracy Zone". ;)


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
MERV GRIFFIN!

[A-Z]+\s*\{

[Brent Dax]

Is this list of special blocks complete and correct?

BEGIN   Executes at the beginning of compilation
CHECK   Executes at the end of compilation
INITExecutes at the beginning of run
END Executes at the end of run
PRE Executes at beginning of block entry
POSTExecutes at end of block entry
NEXTExecutes on call to next() within current block
CATCH   Executes on exception within current block
KEEPExecutes on normal exit of the current block
UNDOExecutes on "un-normal" exit of the current block

--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking and regex hacker

 . hawt sysadmin chx0rs
 This is sad. I know of *a* hawt sysamin chx0r.
 I know more than a few.
 obra: There are two? Are you sure it's not the same one?

Re: [A-Z]+\s*\{

[Bryan C. Warnock]

On Saturday 19 January 2002 22:05, Brent Dax wrote:
> Is this list of special blocks complete and correct?
>
>   BEGIN   Executes at the beginning of compilation
>   CHECK   Executes at the end of compilation
>   INITExecutes at the beginning of run
>   END Executes at the end of run
>   PRE Executes at beginning of block entry
>   POSTExecutes at end of block entry
>   NEXTExecutes on call to next() within current block
>   CATCH   Executes on exception within current block
>   KEEPExecutes on normal exit of the current block
>   UNDOExecutes on "un-normal" exit of the current block

That matches my list.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: [A-Z]+\s*\{

[Me]

> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > Is this list of special blocks complete and correct?
> >
> > BEGIN Executes at the beginning of compilation
> > CHECK Executes at the end of compilation
> > INIT Executes at the beginning of run
> > END Executes at the end of run
> > PRE Executes at beginning of block entry
> > POST Executes at end of block entry
> > NEXT Executes on call to next() within current block
> > CATCH Executes on exception within current block
> > KEEP Executes on normal exit of the current block
> > UNDO Executes on "un-normal" exit of the current block

- LAST
(Per Damian's last (LAST/POST) post.)

- FIRST?
(Symmetry.)

- ALWAYS?
(Another plausible addition. Rounds out PRE and POST
with invariant assertions that get checked twice, once at
the time PRE does, once at the time POST does.
Personally I'd leave this out until it became clear, well
past p6.0, whether it was really worth it, but it seems
worth mentioning.).

--me