On Monday 21 January 2002 11:14, Larry Wall wrote:
> So I'm not terribly interested in going out of my way to make statement
> blocks parse exactly like terms in an ordinary expressions. If it
> happens, it'll probably be by accident.
That's fine. (And I agree.) All I really cared about was ma
Larry Wall writes:
: This is only slightly less problematic than
:
: NEXT $coderef;
:
: which in turn is only slightly less problematic than
:
: if $condition $coderef;
Actually, that'd probably have to be:
if $condition, $coderef;
Still not sure if that has any possibility of ac
Larry wrote:
> : 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...
Sorry, yes, I should have been explic
Larry Wall <[EMAIL PROTECTED]> writes:
> [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
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 d
oderef;
#
# 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 PROTE
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 a
[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
: >
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 ou
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
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?
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
>cal
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 commo
[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-l
"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
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 co
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
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 wan
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
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
> > > EN
> 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 Ex
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
>
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
23 matches
Mail list logo
