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

[Richard Proctor]

On Sun 20 Jan, Me wrote:
> > 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.).
> 

To complete such a list perhaps there is a case for:

NEVER 

:-)

Richard

-- 
Personal   Work - Waveney Consulting
Mail: [EMAIL PROTECTED]  [EMAIL PROTECTED]
Web:  http://www.waveney.org   http://www.WaveneyConsulting.com
Independent Telecommunications Consultant, ATM expert, Web Analyst

Re: Apoc 4?

[iain truskett]

* Bryan C. Warnock ([EMAIL PROTECTED]) [20 Jan 2002 05:33]:
> On Saturday 19 January 2002 12:20, iain truskett wrote:
[...]
> > It's a worry. Also odd is that Slashdot hasn't picked it up yet.

> Developers' section.

/me fossicks through configuration.

Ah. Didn't have 'Collapse Sections' enabled. This also explains why
there's only 4 comments.

Time I removed more of the crud sections.

Cheers for that.


-- 
iain.  

Re: Apo4: PRE, POST

[damian]

> > [concerns over conflation of post-processing and post-assertions]
> 
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").

Larry and I discussed it over breakfast the next day, and concluded that
there will be a LAST block *and* a POST block. With the appropriate
semantics differences.

Damian

Apo4 misc (given nothing, ->, break, c::, keep/undo, hierarchy)

[Me]

> "given nothing...":
>
> given () { ... }

do  { ... }

seems simpler.




> Suppose you want to preserve $_ and alias
>
>given $value -> $g {

'->' seems more visually noisy than it need be in this case.

Perhaps:

given $value as $g { ... }

for @foo as $f { ... }

But, I can see how

> for 0 .. Inf; "a" .. "z" x 1000 -> $i; $a {

for 0 .. Inf; "a" .. "z" x 1000 as $i; $a {

would be seen as a counterexample by some.




> Similarly, if we make a word to mean to explicitly break
> out of a topicalizer, it should not be last. I'd suggest break!

> So it looks to me like we need a break.

I'm glad Larry didn't suggest 'done', because I really enjoyed Apo4.
I'll suggest it instead.




> I also happen to think that Exception is too long a name to
> prefix most common exceptions...

>c::NEXT

Based purely on visual impact, c:: seems best.

Perhaps 'when', or CATCH, could cause the parser to automatically
try an Error:: (or Exit:: or whatever) class prefix when it encounters a
classname.




> KEEP blocks would only be executed if the block succeeded.
> UNDO blocks would only be executed if the block failed.

What defines success? I sometimes raise exceptions to signal
that I'm done, with success, and it's time to wrap up and go back
to some calling code several levels up the stack. But I guess this
is an unusual case so not being able to use KEEP and UNDO
as intended is OK.

Or maybe each block has a Success class exception object
associated with it unless a different exception is raised, and
KEEP is called if the exception isa(Success). Then I can raise
a subclass of Success.



> However, X::Control exceptions (such as X::NEXT) are a
> subset of Exceptions
..
..
> Where exactly control exceptions fit in the class hierarchy is
> still open to debate

What about a change of perspective and terminology:

Exit (or Flow)
NEXT
Exception

ie exeptions are a subset of the ways to exit a block.


--me

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

[damian]

On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > Is this list of special blocks complete and correct?

Close and close. As of two days ago, Larry's thinking was:

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 block entry.
Inherited if block is a method. No side-effects 
allowed.
POSTExecutes at block exit.
Inherited if block is a method. No side-effects 
allowed.
NEXTExecutes on (explicit or implicit) call to next()
within current block
CATCH   Executes on exception within current block
LASTExecutes on any form of block exit. 
Not inherited (c.f. POST), even if block is a method. 
Side-effects allowed.
KEEPSpecialized form of CATCH.
Executes on "control" exception in the current block
UNDOSpecialized form of CATCH.
Executes on non-"control" exception in the current 
block

Damian

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

[damian]

On Sun, 20 January 2002, "Me" wrote 

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

Yup.

> - FIRST?
> (Symmetry.)

No. We feel that such code just goes at the start of the block. Of
course, there's an argument that you might have several entry points to
a block (via C labels) and still want some code executed no matter
where you land inside. I'm just not sure we really want to support that
pathology. ;-)


> - 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.).

I feel the same way. Invariant checking in most Design-by-Contract
systems doesn't work that way, and has another purpose entirely.
Invariants are implicitly POST blocks that are automatically distributed
to *all* methods of the class for which they're defined, but which only
execute on transitions back to callers *outside* that class's hierarchy.


Perl 6 *will* have invariant checking, but I believe it should be via a
property on the class declaration:

class Positive
is always { $.value > 0 }
is always { $.feelings =~ /optimistic/i }
is always { $.polarity eq '+' };


Damian 

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

[Bryan C. Warnock]

On Sunday 20 January 2002 08:29, [EMAIL PROTECTED] wrote:
> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
>
> Close and close. As of two days ago, Larry's thinking was:
>

Note to self: Program flow

>   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

Note to self: Block flow

>   PRE Executes at block entry.
>   Inherited if block is a method. No side-effects 
>allowed.
>   POSTExecutes at block exit.
>   Inherited if block is a method. No side-effects 
>allowed.
>   NEXTExecutes on (explicit or implicit) call to next()
> within current block
>   CATCH   Executes on exception within current block
>   LASTExecutes on any form of block exit.
>   Not inherited (c.f. POST), even if block is a method.
>   Side-effects allowed.
>   KEEPSpecialized form of CATCH.
>   Executes on "control" exception in the current block
>   UNDOSpecialized form of CATCH.
>   Executes on non-"control" exception in the current 
>block


Is it POST, LAST or LAST, POST, at runtime? 

How does one enforce the no side-effects rule, and how deeply does it
traverse?  

Do I remember right that 'return' creates a control exception?

Do KEEP and UNDO take the place of CATCH within a block?  (ie, you may either
CATCH, or you may KEEP and UNDO, but not both?)  If all three are allowed, 
what is the exception handling order?

Which blocks may you have more than one of within the same block, and in 
what order will they execute?

In one cannot (or does not) inherit a PRE, POST, or LAST block, is there a 
way to add one without recreating the entire block.

When you say inheritence (which implies a sub), not inheriting only applies 
to the outer-most scope - the sub scope - currect?  Any container blocks 
should still have their full semantics preserved, so that an embedded while 
block, for instance, would still have its corresponding LAST, I hope.  If 
that were the case, could you then get around the inheritence issue by 
enclosing the entire body of the sub inside its own block?  (I'm not saying 
that that's a good idea, just asking whether it could be done.)

sub non_method {
loop {
PRE {
print "PRE\n"; # Is printing a side-effect?
...
}

POST {
print "POST\n"; 
...
}

LAST {
print "LAST\n";
...
}

code();

last;
}
}


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

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

[Graham Barr]

On Sun, Jan 20, 2002 at 05:29:39AM -0800, Damian Conway wrote:
> On Saturday 19 January 2002 22:05, Brent Dax wrote:
> > > Is this list of special blocks complete and correct?
> 
> Close and close. As of two days ago, Larry's thinking was:
> 
>   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 block entry.
>   Inherited if block is a method. No side-effects 
>allowed.
>   POSTExecutes at block exit.
>   Inherited if block is a method. No side-effects 
>allowed.
>   NEXTExecutes on (explicit or implicit) call to next()
> within current block

If a POST is inside a loop, is it executed at the end of each iteration
or only when the loop exits ?

If it is only when the loop exits, will it be possible to designate
a block to be multiple (eg both POST and NEXT)

Graham.

>   CATCH   Executes on exception within current block
>   LASTExecutes on any form of block exit. 
>   Not inherited (c.f. POST), even if block is a method. 
>   Side-effects allowed.
>   KEEPSpecialized form of CATCH.
>   Executes on "control" exception in the current block
>   UNDOSpecialized form of CATCH.
>   Executes on non-"control" exception in the current 
>block
> 
> Damian
> 
> 

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

[Glenn Linderman]

"Bryan C. Warnock" wrote:
> 
> 
> Is it POST, LAST or LAST, POST, at runtime?

Since POST is checking invariants, and LAST can have side effects, LAST
must be executed before POST.

Apo 4 said POSTs were executed in the reverse of the order seen, I
presume that would hold for LAST as well.

> How does one enforce the no side-effects rule, and how deeply does it
> traverse?

Good question!
 
> Do I remember right that 'return' creates a control exception?

Yes.
 
> Do KEEP and UNDO take the place of CATCH within a block?  (ie, you may either
> CATCH, or you may KEEP and UNDO, but not both?)  If all three are allowed,
> what is the exception handling order?

The way I hear it, KEEP/UNDO get executed if there are control/other
exceptions raised, but they do not themselves catch exceptions.  The
ordering will be interesting to learn... I'd think/hope KEEP or UNDO
would be executed before CATCH.
 
> Which blocks may you have more than one of within the same block, and in
> what order will they execute?

It would be nice to have the chart... Here's my interpretation,
corrections welcomed from those in the know.  I see no reason not to
permit multiple instances of any of the types of blocks, although they
could be restricted as unnecessary (especially those marked "yes?".  It
seems there might not be much reason to allow multiples of those, but
unless there is an implementation reason not to, why not?)


block  side multiple   order
type   effects  instances

PREno   yes?/order seenbefore regular code in block
 inherited before
 locally defined
regular code   yes  n/aafter PRE, until exception
KEEP   yes  yes/reverse order  if control exception, ofter
reg
UNDO   yes  yes/reverse order  if non-control exception,
after reg
CATCH  yes  yes?/order seenafter KEEP/UNDO
  until exception
  is cleaned
LAST   yes  yes/reverse order  after regular code if no
exception
   after CATCH if exception
POST   no   yes?/reverse order after LAST
  locally defined
  before inherited


 
> In one cannot (or does not) inherit a PRE, POST, or LAST block, is there a
> way to add one without recreating the entire block.

Seems like you could always have your own blocks of any kind... just
define them.  In addition, you might inherit one from somewhere else.

-- 
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.

Re: jit2h.pl incredibly slow!

[Daniel Grunblatt]

Now it should be back to something "normal".

Daniel Grunblatt.


On Sun, 13 Jan 2002, Daniel Grunblatt wrote:

> It's slow because it calls Parrot::Jit::Assemble ~1time for each opcode
> and that implies calls to as and objdump.
>
> Daniel Grunblatt.
>
>
> On Sat, 12 Jan 2002, Simon Glover wrote:
>
> >
> >  The latest version of jit2h.pl is taking a very long time to run on my
> >  machine - upwards of two minutes, which is longer than the rest of the
> >  build put together! It doesn't appear to be broken, as Parrot still
> >  builds fine, but it is rather annoying. Any idea what's causing this
> >  slow-down?
> >
> >  Simon
> >
> >
>
>

Re: Apoc4: The loop keyword

[Damian Conway]

"Bryan C. Warnock" wrote:
> 
> 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++ {
> ...
> }

Yes.

 
> How would you use an $x lexically scoped to the loop block?

You can't...directly. Nor can a C or C. The new rule is that
to be lexical to a block it has to be declared in the block, or in the
block's parameter list.

You'd need to use another layer of braces:

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

Damian

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

[Larry Wall]

[EMAIL PROTECTED] writes:
: Is it POST, LAST or LAST, POST, at runtime? 

Obviously you want to put the assertion checking after the cleanup,
so LAST, POST.

: How does one enforce the no side-effects rule, and how deeply does it
: traverse?  

Dunno.  Could warn or fail on assignment to any non-lexical or
non-local lexical as a start.  Maybe we could warn or fail on method
calls known to modify an object.  But I don't know how much
technological enforcement we can achieve without an unnecessarily
fascist declaration policy.  I expect the most important thing would be
to encourage people to think that way.

: Do I remember right that 'return' creates a control exception?

Yes, unless it can be optimized to a goto.

: Do KEEP and UNDO take the place of CATCH within a block?  (ie, you may either
: CATCH, or you may KEEP and UNDO, but not both?)  If all three are allowed, 
: what is the exception handling order?

I think of KEEP and UNDO as LAST blocks, not CATCH blocks, because
there can only be one CATCH block, but there can be multiple LAST
blocks.  They just happen to have secret knowledge of whether the block
was successful or not.  How that interacts with a previously occurring
CATCH is still a little up in the air.  I suppose it should be possible
for a CATCH to signal success even though a "fatal" exception was caught.
I wouldn't think that would be the default, though.  Maybe it has to
wipe out $! manually or change $! to an innocuous exception type for
the KEEPs to run instead of the UNDOs.

: Which blocks may you have more than one of within the same block, and in 
: what order will they execute?

As far as I know, only CATCH is limited to one, and the basic principle
for order is that things that run at the beginning of something run in
forward order, while things that run at the end run in reverse order.

: In one cannot (or does not) inherit a PRE, POST, or LAST block, is there a 
: way to add one without recreating the entire block.

I expect PRE and POST could inherit automatically according to the
usual rules of DbC, though how you implement that is something other
people have thought about more than me.  I think that LAST doesn't
inherit.  If you want to share common code, there's this neat Perl 6
invention called "subroutines" you can use.

: When you say inheritence (which implies a sub), not inheriting only applies
: to the outer-most scope - the sub scope - currect?  Any container blocks
: should still have their full semantics preserved, so that an embedded while
: block, for instance, would still have its corresponding LAST, I hope.

Yes. 

: If that were the case, could you then get around the inheritence issue by
: enclosing the entire body of the sub inside its own block?  (I'm not saying
: that that's a good idea, just asking whether it could be done.)

Yes.

: sub non_method {
: loop {
: PRE {
: print "PRE\n"; # Is printing a side-effect? 

Gee, maybe warnings and failures are side effects, and should be also
prohibited.  :-)

Like I said earlier, I think the important thing is to make people
think about it, not to continually frustrate them.  I'd be inclined to
let people choose their own level of pain by setting DbC strictness
thresholds.

Larry

Build failing

[Melvin Smith]

I think the last jit patch broke config.

perl vtable_h.pl
perl make_vtable_ops.pl > vtable.ops
perl ops2c.pl C core.ops io.ops rx.ops vtable.ops
include/parrot/oplib/core_ops.hperl ops2c.pl CPrederef core.ops io.ops 
rx.ops vtable.ops
include/parrot/oplib/core_ops_prederef.hperl ops2pm.pl core.ops io.ops 
rx.ops vtable.ops
make: *** No rule to make target `Parrot/Jit/i686Generic.pm', needed by 
`Parrot/Jit.pm'.  Stop.
[msmith@linux parrot]$


-Melvin

Re: Apoc4: 'when' blocks versus statements

[Larry Wall]

[EMAIL PROTECTED] writes:
: 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.  

I can see your point.  But emember the principle that important things
go down the left margin.  Therefore any "when" statement modifier is to
be considered unimportant relative to the statement it modifies.  By
that principle, it doesn't break.  Plus it provides a handy skipless
skip syntax for when you want a whole bunch of fallthroughs.  The sum
of those two notions is worth the loss in orthogonality, I believe.  The
"when" is still different from an "if" in preferentially matching
against the given.  And I'd like to discourage people from flipping all
their when clauses around merely to get rid of two curlies.

Larry

Re: Apoc4: The loop keyword

[Larry Wall]

Damian Conway writes:
: "Bryan C. Warnock" wrote:
: > 
: > 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++ {
: > ...
: > }
: 
: Yes.
: 
:  
: > How would you use an $x lexically scoped to the loop block?
: 
: You can't...directly. Nor can a C or C. The new rule is that
: to be lexical to a block it has to be declared in the block, or in the
: block's parameter list.
: 
: You'd need to use another layer of braces:
: 
:   do {
:   loop my $x=0; $x < 100; $x++ {
:   ...
:   }
:   }


In this case, you can get a lexical declarationjust say

for 0...100 -> $x {
...
}

since C<< -> $x >> is considered similar to C, which is
the only other way to declare a "my" variable outside its block.  (In
either case, the lexical defaults to read-only within the block.)

Note the ... there, borrowed from Ruby to mean "leave out the endpoint".

Larry

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

[Bryan C. Warnock]

On Sunday 20 January 2002 20:57, Larry Wall wrote:
> I expect PRE and POST could inherit automatically according to the
> usual rules of DbC, though how you implement that is something other
> people have thought about more than me.  I think that LAST doesn't
> inherit.  If you want to share common code, there's this neat Perl 6
> invention called "subroutines" you can use.

Funny you should say that.  The question I hadn't asked yet:

Since these blocks are all closures now, will the different methods for 
passing code blocks be interchangeable (or simplified)?

User code code can pass '{ ... }' if a sub's prototype wants a coderef, to 
better match map and grep; sort can take a bare block or the name of a sub, 
but none of the three can take a reference to a sub.  Whereas this mostly 
makes (made) sense, can code truly start being interchangable?  Can I write 
reusable transformers and filters for map and grep, simply passing in a ref 
to the proper routine rather than the code block?  How would this interact 
(or react) with curried code blocks?

If this is a good first step, how far can it extend?  Could I write a sub, 
and pass a reference to it directly to LAST, for instance:

LAST $coderef; 

or would I simply wrap it?

LAST {
 &$coderef;
}

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Apoc4: Parentheses

[Larry Wall]

[EMAIL PROTECTED] writes:
: 
: 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.)

Yes, you can use a "my" in those expressions, but now the scope will
continue beyond the inner block, whether or not there are parens.

Larry

Re: Build failing

[Melvin Smith]

>
>make: *** No rule to make target `Parrot/Jit/i686Generic.pm', needed by 
>`Parrot/Jit.pm'.  Stop.
>[msmith@linux parrot]$

Had to patch Configure.pl as follows to get a build on my box.

-Melvin


Index: Configure.pl
===
RCS file: /cvs/public/parrot/Configure.pl,v
retrieving revision 1.82
diff -u -r1.82 Configure.pl
--- Configure.pl20 Jan 2002 20:52:20 -  1.82
+++ Configure.pl21 Jan 2002 02:23:31 -
@@ -149,6 +149,7 @@
  $jitarchname  =  "$cpuarch-$osname";
  $jitarchname =~ s/i[456]86/i386/i;
  $jitarchname  =~ s/-(net|free|open)bsd$/-bsd/i;
+$cpuarch =~ s/i[456]86/i386/i;

  if (-e "Parrot/Jit/$jitarchname.pm") {
  $jitcapable  = 1;

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

[Dan Sugalski]

At 5:57 PM -0800 1/20/02, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: How does one enforce the no side-effects rule, and how deeply does it
>: traverse? 
>
>Dunno.  Could warn or fail on assignment to any non-lexical or
>non-local lexical as a start.  Maybe we could warn or fail on method
>calls known to modify an object.  But I don't know how much
>technological enforcement we can achieve without an unnecessarily
>fascist declaration policy.  I expect the most important thing would be
>to encourage people to think that way.

Anything like that I can see being reasonably expensive to provide in 
the runtime. I'm not sure if it can be done without cost in all 
circumstances either. (We'd need to trap all write access, and I 
can't imagine that being cheap. I admit I'd rather not have to 
imagine a way that it was... :)
-- 

Dan

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

RE: Apoc4: Parentheses

[Sterin, Ilya]

> 
> [EMAIL PROTECTED] writes:
> : 
> : 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.)
> 
> Yes, you can use a "my" in those expressions, but now the 
> scope will continue beyond the inner block, whether or not 
> there are parens.

How would we then create a inner block scoped variable, as for counters
or other variables not needed passed the scope.  The only way would be
to increment within the block itself.

Is there a reason why we can't have behavior defined on whether or not
pareths are used.  With pareths it's scope block, without, outter scope?

Ilya



> 
> Larry
> 

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

[Larry Wall]

[EMAIL PROTECTED] writes:
: The two current examples of an evil expression block are do {} and eval {}, 
: which require a semicolon terminator.  However, with eval {} leaving...

Er, eval {} isn't leaving exactly--it's turning into try {}, which is
also an expression block.   Plus we potentially have BEGIN and INIT as
expression blocks.  Plus any random closures that just happen to show
up in the middle of an expression.

: 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
: };

Hmm, seems like a another good spot to invoke the lone curly rule.

: 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.

If your putting more expression on the line after the }, I'd say you're
not exactly formatting for clarity.  Such formatting encourages the
reader to think that a new statement is starting, who has doubtless by
this time forgotten that it's a "do" and not an "if".  :-)

: 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;

And anyone who puts such a statement modifier on a do {} block deserves
whatever they get.  Statement modifiers are best used on short
statements, not long ones.

: 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. 

Form and content are deeply intertwingled in the human psyche.

: 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?

CHECK doesn't make sense, nor any other block-exiting hooks, since they
aren't run till after the surrounding code is done.  PRE is a
possibility, though perhaps not sensical from a DbC point of view.  If
there *were* a FIRST block, it would be an expression block.

: 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?

By that argument, we wouldn't ever change anything.  :-)

: 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.

I think it's too easy to have accidental non-void contexts, which is
why I'm wanting to out

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

[Bryan C. Warnock]

On Sunday 20 January 2002 21:43, Larry Wall wrote:
>
> I think it's too easy to have accidental non-void contexts, which is
> why I'm wanting to outlaw bare blocks at the statement level.  But I
> don't think that fact influences your argument one way or the other.
> There's definitely some merit in what you say--I'm just not sure the
> distant context should outweigh the close context when the block could
> be arbitrarily long.

My concern is that we're simply replacing one set of questions ("why doesn't 
this work the way I expect") with another set of questions ("why doesn't 
this work the way I expect").  I'm sure that would hold true for any amount 
of change, so I want to be prepared with the rationale and explanations.

Thanks for answering my queries.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Build failing

[Daniel Grunblatt]

Fixed, Thanks.

Daniel Grunblatt.


On Sun, 20 Jan 2002, Melvin Smith wrote:

>
> >
> >make: *** No rule to make target `Parrot/Jit/i686Generic.pm', needed by
> >`Parrot/Jit.pm'.  Stop.
> >[msmith@linux parrot]$
>
> Had to patch Configure.pl as follows to get a build on my box.
>
> -Melvin
>
>
> Index: Configure.pl
> ===
> RCS file: /cvs/public/parrot/Configure.pl,v
> retrieving revision 1.82
> diff -u -r1.82 Configure.pl
> --- Configure.pl20 Jan 2002 20:52:20 -  1.82
> +++ Configure.pl21 Jan 2002 02:23:31 -
> @@ -149,6 +149,7 @@
>   $jitarchname  =  "$cpuarch-$osname";
>   $jitarchname =~ s/i[456]86/i386/i;
>   $jitarchname  =~ s/-(net|free|open)bsd$/-bsd/i;
> +$cpuarch =~ s/i[456]86/i386/i;
>
>   if (-e "Parrot/Jit/$jitarchname.pm") {
>   $jitcapable  = 1;
>
>
>
>

Re: Apoc4: The loop keyword

[Michael G Schwern]

On Sun, Jan 20, 2002 at 07:25:17PM -0500, Damian Conway wrote:
> > How would you use an $x lexically scoped to the loop block?
> 
> You can't...directly. Nor can a C or C. The new rule is that
> to be lexical to a block it has to be declared in the block, or in the
> block's parameter list.
> 
> You'd need to use another layer of braces:
> 
>   do {
>   loop my $x=0; $x < 100; $x++ {
>   ...
>   }
>   }

Hmmm.  I understand the desire for lexical simplicity and all, but
this seems like a Great Leap Backwards to 5.003.

{
my $foo;
foreach $foo (@bar) {
...
}
}

The C $foo> is a good out for the common case, and
I'll give that more complicated for loops will be uncommon enough so
having a few block wrappers won't matter.  But I'm worried about how
will we replicate the current behavior of the common idiom:

while( my $line =  ) {
...
}

Will it be:

while  -> $line {
...
}

or do we have to start wrapping things up?

And then there's this one:

if( my $foo = bar() ) {
...
}

how would that be written?


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
It wasn't false, just differently truthful.
-- Abhijit Menon-Sen in <[EMAIL PROTECTED]>

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

[Damian Conway]

Bryan C. Warnock asked:


> Is it POST, LAST or LAST, POST, at runtime?

LAST then POST I suspect. For reasons already given in someone else's
reply. But, just possibly: intermixed in reverse order of definition.


> How does one enforce the no side-effects rule, and how deeply does it
> traverse?

By prohibiting mutation of variables not lexical to the block,
forbidding I/O, allowing calls only to already-defined subs, and
applying the same restrictions recursively to those subs.

 
 
> Do I remember right that 'return' creates a control exception?

Yes.

 
> Do KEEP and UNDO take the place of CATCH within a block?  (ie, you may
> either CATCH, or you may KEEP and UNDO, but not both?

Correct. KEEP+UNDO = CATCH and you can only have one CATCH per block.


> If one cannot (or does not) inherit a PRE, POST, or LAST block,

LAST blocks aren't ever inherited.


> is there a way to add one without recreating the entire block.

Probably not. If there were, it would be via the block's MY pseudoclass
and be subject to the same "compile-time modifications only" constraints
as other up-scope lexical manipulations.


> When you say inheritence (which implies a sub)

implies a method. Not the same thing in Perl 6.

> not inheriting only applies to the outer-most scope - the sub scope -
> currect?  Any container blocks
> should still have their full semantics preserved, so that an embedded
> while block, for instance, would still have its corresponding LAST

Of course.

> If that were the case, could you then get around the inheritence issue
> by enclosing the entire body of the sub inside its own block?  (I'm
> not saying that that's a good idea, just asking whether it could be 
> done.)

Err. I'm afraid you lost me there. What are you trying to achieve, again?


> sub non_method {
> loop {
> PRE {
> print "PRE\n"; # Is printing a side-effect?
> ...
> }

Printing can be a side effect. For example, your example modifies a
global filehandle.

Damian

Re: Apoc4: Parentheses

[Damian Conway]

Bryan C. Warnock asked:

> 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.)

Err. Expressions don't have their own scope level, even in Perl 5.

Try this:

$y = "package y";
$x = ! defined my $y;
print "[$y]\n";


Damian

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

[Damian Conway]

Graham Barr wrote:

> If a POST is inside a loop, is it executed at the end of each
> iteration or only when the loop exits ?

Only on final exit.

> If it is only when the loop exits, will it be possible to designate
> a block to be multiple (eg both POST and NEXT)

One way to do that would be to define POST and NEXT to return their own
(single, closure) argument. So then you could write:

NEXT POST { ... }


Damian

Re: Apo4 misc (given nothing, ->, break, c::, keep/undo, hierarchy)

[Damian Conway]

Me wrote:

> > "given nothing...":
> >
> > given () { ... }
> 
> do  { ... }
> 
> seems simpler.

But doesn't have the same effect. A C inside a C responds to
the current value of the "subject" specified by any surrounding
topicalizer (i.e. C, C, C, etc.)


> 
> > Suppose you want to preserve $_ and alias
> >
> >given $value -> $g {
> 
> '->' seems more visually noisy than it need be in this case.
>
> Perhaps:
> 
> given $value as $g { ... }
> 
> for @foo as $f { ... }
> 
> But, I can see how
> 
> > for 0 .. Inf; "a" .. "z" x 1000 -> $i; $a {
> 
> for 0 .. Inf; "a" .. "z" x 1000 as $i; $a {
> 
> would be seen as a counterexample by some.

Yep. By Larry, for one. And me, for another. ;-)


> > KEEP blocks would only be executed if the block succeeded.
> > UNDO blocks would only be executed if the block failed.
> 
> What defines success? I sometimes raise exceptions to signal
> that I'm done, with success, and it's time to wrap up and go back
> to some calling code several levels up the stack. But I guess this
> is an unusual case so not being able to use KEEP and UNDO
> as intended is OK.

Just derive your "successful exception" from Control:: rather that
Error:: (or whatever the final standard names are).

> Or maybe each block has a Success class exception object
> associated with it unless a different exception is raised, and
> KEEP is called if the exception isa(Success). Then I can raise
> a subclass of Success.

Yep. Just s/Success/Control or whatever Larry decides/

Damian

Re: Apoc4 - A little wish

[Damian Conway]

> 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.


* He didn't want a keyword that would become lost when lots of variables 
  or sub calls are used in the setup.

* Using "in" doesn't work well linguistically with "given", "sort",
  "map", etc:

given $var in $x {...}

@data = sort in $i, $j {...} @data;

@data = map in $x {...} @data;


* The left-to-right sequencing of -> keeps the data near the "for" and 
  the aliases near the block.

* Gives the poor discarded -> a new lease on life as a synonym for "sub"

* New inline code smiley face possible:

my $sum =-> @data { shift @data + $sum(@data) }

;-)

Damian

PS: It's "for" not "foreach". "Tha ken be onla wun!"

Re: Ex4, Apo5, when ?

[Damian Conway]

> >>  It may be a bit before Ex4 is done. Damian's on a cruise ship at
> >>  the moment, so even if he's got the time (and I don't think he
> >>  does) he's likely lacking connectivity. I expect he'll give us
> >>  word at some point what the schedule is.
> >
> >They've got connectivity all right.  We've been getting plenty of
> >drunken ramblings on IRC from folks on the cruise.
> 
> Well, so much for *that* excuse. :) Bet they're still hard up for
> free time, though.

Yep. Larry and I and the rest of the speakers are on board to give folks
a chance to interact with us. Hard to do if I'm holed up in my cabin
typing. 

Besides, I need a little "reaction" from the community, so I can see
what most needs to be elucidated.

E4 should be out some time later this week.

Damian

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

[Damian Conway]

Damian Conway wrote (apparently whilst on stupid pills):

> > Do KEEP and UNDO take the place of CATCH within a block?  (ie, you
> > may either CATCH, or you may KEEP and UNDO, but not both?
> 
> Correct. KEEP+UNDO = CATCH and you can only have one CATCH per block.

As Larry has already pointed out: KEEP + UNDO = LAST, not CATCH.
Hence you can have as many of them as you need.

Nurse! It must be time for my medication! %-)

Damian

Re: A question

[Larry Wall]

Piers Cawley writes:
: Yeah, that's sort of where I got to as well. But I just wanted to make
: sure. I confess I'm somewhat wary of the ';' operator, especially
: where it's 'unguarded' by brackets, and once I start programming in
: Perl 6 then 
: 
: for (@aaa ; @bbb -> $a; $b) { ... }
: 
: will be one of my personal style guidelines.

That is likely a syntax error, because the -> is not an operator, but a
kind of unary keyword like "sub", and it binds the righthand arguments
to the following block.  You'd have to say:

for (@aaa; @bbb) -> ($a; $b) { ... }

Larry

Re: Apoc4 - A little wish

[Larry Wall]

Angel Faus writes:
: ¿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.

Certainly.  That's how things like

for 0 .. Inf -> $x { ... }

work.  We're certainly not going to generate all the values before
we start the loop...

: 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).

for <$fh> -> $line { print $line }

: 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. [:)]

We'll schedule a clear conclusion to all this sometime after 6.0.0
comes out. :-)

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

Yes, though Perl 5's closures are just as powerful already.  What's needed
is some syntactic relief, however, so that it's easier to pass closures
other than as the first argument.  The

-> $x { ... }

notation is the equivalent of Ruby's {|x| ... } notation.  But in Perl
you can pass the closure as any argument that wants a &block--it
doesn't have to come last.  Nor does it come in as a magical hidden
parameter.  And the equivalent of "yield" is simply &block().  (We'll
hold the yield keyword in reserve for returning a value without
returning control from a (thread, coroutine, iterator, generator,
continuation, whatever).

Larry

Re: Apoc4: Parentheses

[Larry Wall]

Sterin, Ilya writes:
: How would we then create a inner block scoped variable, as for counters
: or other variables not needed passed the scope.  The only way would be
: to increment within the block itself.

The only way to declare a lexical variable outside a block for use only
inside the block is to declare it as a formal parameter via C or
C<< -> >>  Inside the block you use C as usual.  However, you can
always increment such a variable:

while 1 {
my $i; FIRST { $i = 0 }; NEXT { $i++ }
}

Hmm, maybe we do need a FIRST to go with the LAST...

: Is there a reason why we can't have behavior defined on whether or not
: pareths are used.  With pareths it's scope block, without, outter scope?

That would be the first time parens ever indicated that sort of thing
in Perl.  And I'd rather not overload the meaning of parens any more
than it already is.

Larry

Re: Apoc4: The loop keyword

[Larry Wall]

Michael G Schwern writes:
: On Sun, Jan 20, 2002 at 07:25:17PM -0500, Damian Conway wrote:
: > > How would you use an $x lexically scoped to the loop block?
: > 
: > You can't...directly. Nor can a C or C. The new rule is that
: > to be lexical to a block it has to be declared in the block, or in the
: > block's parameter list.
: > 
: > You'd need to use another layer of braces:
: > 
: > do {
: >   loop my $x=0; $x < 100; $x++ {
: >   ...
: >   }
: > }
: 
: Hmmm.  I understand the desire for lexical simplicity and all, but
: this seems like a Great Leap Backwards to 5.003.
: 
: {
: my $foo;
: foreach $foo (@bar) {
: ...
: }
: }
: 
: The C $foo> is a good out for the common case, and
: I'll give that more complicated for loops will be uncommon enough so
: having a few block wrappers won't matter.  But I'm worried about how
: will we replicate the current behavior of the common idiom:
: 
: while( my $line =  ) {
: ...
: }

That still works fine--it's just that $line lives on after the while.

: Will it be:
: 
: while  -> $line {
: ...
: }
: 
: or do we have to start wrapping things up?

I don't think C feeds its boolean to its block as a parameter,
so that probably doesn't work.  But this would work fine:

for  -> $line {
...
}

: 
: And then there's this one:
: 
: if( my $foo = bar() ) {
: ...
: }
: 
: how would that be written?

Just the same, only $foo lives on after the block.

I suppose we *could* say that scalar thingies like C and C
can feed their value to the following block as a parameter if you use
the -> notation.  Then you could say

if bar() -> $foo { ... }

But that seems a little bizarre, and I don't know all the implications.
It would seem to imply that if you don't specify a binding for the value
it should default to

if bar() -> $_ { ... }

and I think that's probably not what people will expect.  Boolean ops
like C and C should probably stay boolean, and not become
topicalizers like C and C.  As it is, we're gonna have
a tricky time making sure lexical $_ propagates into closures in
an intuitive fashion.

Larry

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

[Larry Wall]

[EMAIL PROTECTED] writes:
: On Sunday 20 January 2002 20:57, Larry Wall wrote:
: > I expect PRE and POST could inherit automatically according to the
: > usual rules of DbC, though how you implement that is something other
: > people have thought about more than me.  I think that LAST doesn't
: > inherit.  If you want to share common code, there's this neat Perl 6
: > invention called "subroutines" you can use.
: 
: Funny you should say that.  The question I hadn't asked yet:
: 
: Since these blocks are all closures now, will the different methods for 
: passing code blocks be interchangeable (or simplified)?

I don't think we can completely simplify it.  The following two are
certainly interchangeable:

-> $a, $b { $a <=> $b }
{ $^a <=> $^b }

except that the first one can do things like:

-> $a is rw, $b { $a = $b }

while the second automatically does currying.
 
Certainly your good old-fashioned

sub ($a is rw, $b) { $a = $b }

can be used anywhere a CODE pointer is expected at runtime.  I don't
know if I like

for @foo sub ($x) { ... }

but it could be made to work, provided we force C to start a term
as we've done with -> and left curly.  I don't feel greatly motivated
to do that, however.

: User code code can pass '{ ... }' if a sub's prototype wants a coderef, to 
: better match map and grep; sort can take a bare block or the name of a sub, 
: but none of the three can take a reference to a sub.  Whereas this mostly 
: makes (made) sense, can code truly start being interchangable?  Can I write 
: reusable transformers and filters for map and grep, simply passing in a ref 
: to the proper routine rather than the code block?  How would this interact 
: (or react) with curried code blocks?

I don't know how far we can push it.  Certainly it would be really weird
to expect

BEGIN $code;

to work unless their were an earlier BEGIN that happened to set $code.
But if BEGIN has a prototype of (&), perhaps it's just parsed as a unary
operator and that just works.  On the other hand, that's not how the
first argument of

grep $_, @foo

currently works in Perl 5.  In that case, the first argument is being
forced to be treated as if it were curried:

grep $^a, @foo

But that means that $_ can't contain a sub reference!  I suspect that
we have to outlaw forms of grep in which $_ auto-curries itself if we
want

grep $somesub, @foo

To be the same as

grep { $somesub() } @foo

I think it's fair to trade auto-currying of $_ for that flexibility.

: If this is a good first step, how far can it extend?  Could I write a sub, 
: and pass a reference to it directly to LAST, for instance:
: 
: LAST $coderef; 
: 
: or would I simply wrap it?
: 
: LAST {
:  &$coderef;
: }

Well, a wrapper will always work, except that's not how you'd write it
in Perl 6.  The & doesn't call the sub, the parens do.  So you'd have
to say

LAST {
 $coderef();
}

What I can't figure out is, when you write

LAST $coderef;

when would it actually do the %MY._LAST_list.push($coderef)?
Unfortunately, I think it has to do it at compile time, or we can't
guarantee that the LAST actually gets run if an exception is thrown
early.  And in that case, $coderef is likely not set yet.  This seems
like a recipe for confusion, if not disaster.

At the end of the day, I suspect [A-Z]+ blocks will really want to be
literal blocks because we want to do various sorts of analysis of
them at compile time.  We wouldn't be able to tell at compile time if

POST $coderef;

does any horrible side effects, for instance, unless we guarantee that
$coderef is defined when the POST is compiled.  I think we'd often
have people trying to write things like:

my $coderef = sub { ... };
LAST $coderef;

and then wondering why it says "Undefined LAST block" or some such.

Larry

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

[Larry Wall]

Damian Conway writes:
: Graham Barr wrote:
: 
: > If a POST is inside a loop, is it executed at the end of each
: > iteration or only when the loop exits ?
: 
: Only on final exit.
: 
: > If it is only when the loop exits, will it be possible to designate
: > a block to be multiple (eg both POST and NEXT)
: 
: One way to do that would be to define POST and NEXT to return their own
: (single, closure) argument. So then you could write:
: 
:   NEXT POST { ... }

As long as everyone realizes that that return happens at compile time...

This is only slightly less problematic than

NEXT $coderef;

which in turn is only slightly less problematic than

if $condition $coderef;

Ick.

Larry

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

[Brent Dax]

Larry Wall:
# What I can't figure out is, when you write
#
# LAST $coderef;
#
# when would it actually do the %MY._LAST_list.push($coderef)?
# Unfortunately, I think it has to do it at compile time, or we can't
# guarantee that the LAST actually gets run if an exception is thrown
# early.  And in that case, $coderef is likely not set yet.  This seems
# like a recipe for confusion, if not disaster.
#
# At the end of the day, I suspect [A-Z]+ blocks will really want to be
# literal blocks because we want to do various sorts of analysis of
# them at compile time.  We wouldn't be able to tell at compile time if
#
# POST $coderef;
#
# does any horrible side effects, for instance, unless we guarantee that
# $coderef is defined when the POST is compiled.  I think we'd often
# have people trying to write things like:
#
# my $coderef = sub { ... };
# LAST $coderef;
#
# and then wondering why it says "Undefined LAST block" or some such.

Maybe all of the [A-Z]+'s get defined each time the block is entered
(or, if the block is being iterated on, the first time the block is
entered during this set of iterations).

--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*\{

[Larry Wall]

Brent Dax writes:
: Larry Wall:
: # I think we'd often
: # have people trying to write things like:
: #
: # my $coderef = sub { ... };
: # LAST $coderef;
: #
: # and then wondering why it says "Undefined LAST block" or some such.
: 
: Maybe all of the [A-Z]+'s get defined each time the block is entered
: (or, if the block is being iterated on, the first time the block is
: entered during this set of iterations).

That would still leave $coderef undefined in the above snippet.

Larry