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
* 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.
[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
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 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 Cgoto labels) and still want
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
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
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
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
[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
[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
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
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
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
[EMAIL PROTECTED] writes:
: QUOTE
: 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
[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
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
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 Cwhile or Cif. 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.
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?
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
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
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.
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:
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) { ... }
:
:
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
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 Cwhile or Cif. The new rule is that
: to be lexical to a block it has to be declared in the block, or
[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 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
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
29 matches
Mail list logo