Re: Loop controls
Hmmm... some discussion generated on this subject, but fairly light. I take that as an indicator that an Celse on loops is a fairly popular idea. The other possibilities are that b) people don't want any form of else on loops and aren't saying so or c) people simply don't care, but silence and apathy just don't seem to be vices we're afflicted with in this community. ;) My confession for the day is: I actually like the if-like Celse blocks on loops. But attacking a problem from an alternate angle is a valuable exercise. In this case: Taking this perspective made me realize that there is a significant semantic difference between the various new uses of Celse. But, in linguistic terms, it is a perfectly valid to have a range of meaning associated with a word (I mean related senses, not homophones or homographs, e.g. think of as many uses as you can for the noun handle), the human brain is well adapted to it. Still, it will need to be taught, or at least glossed-over-with-full-conciousness-that- it's-being-glossed-over, like the semantic difference between Cif statements and Cif modifiers. I also realized that there is a chance for user error in expecting certain values to be accesible outside their scope in the Celse block. But, I'd rather teach (and use) a clear, well defined, unchanging rule of scope than a handful of exceptions any day. As I was talking to Damian, he came up with a compelling semantic argument why we would want Celse blocks to follow, which is a question that needed to be faced since we rejected Ccontinue. But he should be posting not too long after me (allow for time zone differences), so I won't steal his thunder (well, not too much anyway :). And the discussion of scope led to (what I think is) an interesting tidbit on NAMED blocks (duplicate comment on thunder). BTW, a few nails in the coffin I didn't mention: having an Celse and an CELSE is confusing. It's bad enough that we have Clast and CLAST, etc., at least the lowercase keywords there don't have associated blocks. And something just feels right about Celse blocks on loops. It fits in with that Perlish pattern of allowing structures that feel so natural you wonder why no other language ever allowed them. Allison
Re: Loop controls
On Sat, Apr 27, 2002 at 05:20:06AM -0500, Allison Randal wrote: Hmmm... some discussion generated on this subject, but fairly light. I take that as an indicator that an Celse on loops is a fairly popular idea. The other possibilities are that b) people don't want any form of else on loops and aren't saying so or c) people simply don't care, but silence and apathy just don't seem to be vices we're afflicted with in this community. ;) Here's another possibility. People trust Larry to get it right and don't feel the need to weigh in with opinions. Had I designed Perl there would have been an elsunless and I would have used it. Now I'm glad there isn't an elsunless and I never had the chance to use it :-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Loop controls
On Sat, Apr 27, 2002 at 10:53:09PM +1000, Damian Conway wrote:
Allison wrote:
And the discussion of scope led to (what I think is) an interesting
tidbit on NAMED blocks...
Which I presume was that the proposed usage:
while $result.get_next() - $next {
# do something with $next...
ELSE {
if $next eq xyz572 {
print We defined this value, $next, as false for obscure purposes.;
print No loop was executed. Just wanted to let you know.;
}
}
}
would actually be a (very subtle and nasty) bug!
The construct:
- $next {...}
is, of course, an anonymous subroutine declaration. Hence C$next is
a parameter, the binding of which only occurs when the subroutine is
invoked (i.e. on each iteration). However, if the Cwhile condition
fails, the subroutine *isn't* invoked, so C$next isn't bound, so the
nested CELSE block (even if it were fired off separately) wouldn't
work as expected.
Yes, that's what I meant. You see, I had visualized a slightly different
(and more convoluted) order of events in which the parameter was bound
anyway and the NAMED blocks were set up as triggers associated with
the block early enough in the complilation process that they would be
available at run-time when a skipping this block event occurred. But
this is much cleaner and more efficient in execution. And if you really
need a meta way of knowing *why* the .get_next() method returned a false
value, throw an exception and catch it. Of course, you can't catch it in
the Celse block. You'll have to catch it in a block wrapped around the
whole Cwhile...else construct. But the times when you need that level
of detail will probably be far less frequent than the times when you
just want to know the loop didn't execute.
This leads me to conclude that a normal (trailing, un-nested) Celse
is a much more reasonable construct for a Cwhile -- and at least
arguable for a Cfor.
And Cloop, I hope.
Allison
Re: Loop controls
Allison wrote:
This leads me to conclude that a normal (trailing, un-nested) Celse
is a much more reasonable construct for a Cwhile -- and at least
arguable for a Cfor.
And Cloop, I hope.
Sure. I always think of a Cloop as just a Cwhile with delusions of
grandeur. ;-)
Of course, one would expect a compile-time warning on useless special cases like:
loop {
...
}
else {
...
}
Damian
Re: Loop controls
Allison Randal wrote: Hmmm... some discussion generated on this subject, but fairly light. I take that as an indicator that an Celse on loops is a fairly popular idea. The other possibilities are that b) people don't want any form of else on loops and aren't saying so or c) people simply don't care, but silence and apathy just don't seem to be vices we're afflicted with in this community. ;) I actually like Andy Wardly's suggestion of iterators. It makes a lot of sense and looks a lot cleaner to read and write and adds less new syntax to remember (and parse). Clayton
Going meta to tagmemic rhetoric (was Re: Loop controls)
On Sat, Apr 27, 2002 at 12:50:49PM +0200, Paul Johnson wrote: Here's another possibility. People trust Larry to get it right and don't feel the need to weigh in with opinions. I trust Larry. That's actually why I feel free to play the devil's advocate. I trust him to toss the dross and pick out the uncut diamonds and make something useful out of them. We've all seen how he can come into a discussion, pull the good bits out of various viewpoints and present us with a solution that is greater than the sum of the discussion. It occurs to me that it might be beneficial to lay a philosophical groundwork for the Demosthenes Posts and for the Perl 6 multilogue in general. Did I mention that tagmemics goes far beyond mere syntax? Out of this originally linguistic inquiry have come the bases of tagmemic rhetoric, which posits composing as a problem-solving process and recenters the goal of rhetoric away from the narrower concerns of Aristotelian persuasion toward the broader goal of building bridges between rhetors who profess potentially conflicting worldviews, bridges that make possible both discovery of alternatives and volitional change. From the tagmemic point of view, every rhetor's task is inevitably analogous to the kinds of challenges alien translators in a new cultural environment encounter: locating a point of entry into a particular language ambiguity, problem, or challenge that will provide a true bridge for nonthreatening exchange and that, therefore, might make possible meaningful change. [0] The individual ideas don't matter. It is the process that matters, the dialog that leads to deeper understanding of the problems, and to better solutions. It is the outcome that matters, a Perl that is better and cleaner and easier to use (yes, it really is easier), and is still Perl. Larry has said he'd like this to be the community's rewrite of Perl. How can it be that if we keep silent? The RFC's were the beginning, but we've had a course change of a few degrees since then which has taken us past interesting challenges no-one anticipated. So we talk, not in competition or from lack of trust but as an involved community. It's also fun. :) Allison [0] This is taken from Bruce L. Edwards: http://personal.bgsu.edu/~edwards/tags.html
