On Fri, May 17, 2002 at 05:40:30PM -0600, Luke Palmer wrote:
> Back to from where this arose, however, I think LAST (and BETWEEN, if
> it will exist) should probably be PRE blocks. This is the only way it
> could be consistently possible to implement. It wouldn't make any
> sense to have it a PRE
On 16 May 2002, Aaron Sherman wrote:
> On Thu, 2002-05-16 at 16:13, David Whipp wrote:
> > Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> > > You might not be able to REASONABLY get a length, so you return
> > > undef. In your documentation, you advise users not to take the length,
> > > but j
--
On Thu, 16 May 2002 12:36:42
Miko O'Sullivan wrote:
>SUMMARY
>
>Arrays should always have known lengths because that's what arrays do. This
>requirement is enforced culturally, not programmatically.
I totally agree that this should be enforced culturally. I think that the way a tied
On Thu, 2002-05-16 at 16:13, David Whipp wrote:
> Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> > You might not be able to REASONABLY get a length, so you return
> > undef. In your documentation, you advise users not to take the length,
> > but just dive right in and fetch the element you want
On Thursday 16 May 2002 01:13 pm, David Whipp wrote:
> Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> > You might not be able to REASONABLY get a length, so you return
> > undef. In your documentation, you advise users not to take the length,
> > but just dive right in and fetch the element you
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> You might not be able to REASONABLY get a length, so you return
> undef. In your documentation, you advise users not to take the length,
> but just dive right in and fetch the element you want, e.g.:
>
> my $pi2k = @pi_digits[2000];
In this ca
On Thu, 2002-05-16 at 12:36, Miko O'Sullivan wrote:
> I submit for consideration the idea that if an array doesn't always have a
> defined length then it ceases to be that incredibly handy construct that we
> currently call "array". If arrays can answer "I dunno" when asked how long
> they are,
SUMMARY
Arrays should always have known lengths because that's what arrays do. This
requirement is enforced culturally, not programmatically.
DETAILS
I submit for consideration the idea that if an array doesn't always have a
defined length then it ceases to be that incredibly handy construct t
On Wed, 2002-05-15 at 13:02, Larry Wall wrote:
> Aaron Sherman writes:
> : Should a tied and/or lazy array be forced to present a length on demand,
> : or can length return undef on indeterminate arrays?
>
> An array implementation can return anything it jolly well pleases, but
> I'd say undef wo
Aaron Sherman writes:
: Should a tied and/or lazy array be forced to present a length on demand,
: or can length return undef on indeterminate arrays?
An array implementation can return anything it jolly well pleases, but
I'd say undef would be a reasonable thing to return if the length is
indete
On Sun, 2002-05-12 at 15:43, Miko O'Sullivan wrote:
> From: "David Whipp" <[EMAIL PROTECTED]>
> > It it too much to ask, of the creator of a tied array, to implement
> > their code in such a way that *reading* an element of that array
> > does not have significant side-effects?
>
> Actually, I th
In a message dated Sun, 12 May 2002, Miko O'Sullivan writes:
> From: "David Whipp" <[EMAIL PROTECTED]>
> > It it too much to ask, of the creator of a tied array, to implement
> > their code in such a way that *reading* an element of that array
> > does not have significant side-effects?
>
> Actua
From: "David Whipp" <[EMAIL PROTECTED]>
> It it too much to ask, of the creator of a tied array, to implement
> their code in such a way that *reading* an element of that array
> does not have significant side-effects?
Actually, I think that *is* a significant imposition. The whole point of
tied
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> From: "Damian Conway" <[EMAIL PROTECTED]>
>> while (my $res = $search->getnext) { ...}
>>
>> has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
>> reasonable than in Perl 5.
>
> I don't think the new meaning makes sense at al
From: "Damian Conway" <[EMAIL PROTECTED]>
> while (my $res = $search->getnext) { ...}
>
> has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
> reasonable than in Perl 5.
I don't think the new meaning makes sense at all. Essentially it's saying
"the statement gets run many
> Ok, now I understand the plan. In brief, in the following example $result
> is scoped to the block that encloses the whole loop:
>
>while (my $res = $search->getnext) { ...}
Yes. Because it's a lexical variable declared outside the closure controlled
by the C.
> However, in the next exa
> while getNextValue() -> $i {
> ...
> }
>
> while getOtherNextValue() -> $i {
> ...
> }
>
> which generates no warning because each C<$i> is a parameter of the
> corresponding loop block, and hence scoped to that block.
Ok, now I understand the plan. In brief, in the following example $result
i
On Thu, 2002-05-09 at 13:22, David Whipp wrote:
> Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> > what about
> > >
> > > while (do_something_with_side_effects_and_check_still_ok()) {
> > >
> > > I presume we don't want to do look-ahead here.
> >
> > Yes, I think he was saying exactly
Miko O'Sullivan wrote:
> Just checking here: is PRE_LAST a separate and non-mutually exclusive
> concept from LAST? I.e., would this make sense:
>
>foreach @arr -> $i {
> PRE_LAST {print "before last loop\n"}
> LAST {print "after last loop\n"}
> print "$i\n";
>}
>
> If
> The implication is that we can only provide advanced "PRE_LAST"
> style blocks (or their equiv.) on the C loop. The fact
> that they are impossible on the C loop should not
> constrain our thinking for the C loop.
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept fro
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> what about
> >
> > while (do_something_with_side_effects_and_check_still_ok()) {
> >
> > I presume we don't want to do look-ahead here.
>
> Yes, I think he was saying exactly that we will do look-ahead
> here. "we don't guarantee order of
On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
> On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
> >
> > LAST Executes on implicit loop exit or call to last()
> > Loop variables may be unknown
>
> Not exactly "unknown". It's just that, in a few cases, their v
On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
>
> LAST Executes on implicit loop exit or call to last()
> Loop variables may be unknown
Not exactly "unknown". It's just that, in a few cases, their values may
have changed by the time the LAST block is executed.
> And I th
I have been following this thread, but I would just like to inject a summary
of the various related UPPERCASE blocks
PREExecutes on block entry.
Loop variables are in a known state
POST Executes on block exit.
Loop variables are in a known state
NEXT Executes on impli
On Mon, 2002-05-06 at 14:21, David Whipp wrote:
> Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
> > Sorry, I thought I'd expressed agreement at some point. I like the
> > "else\s+(if|while|for|loop)" construct very much, and I think the
> > programmers of the world would like it too. I know
On Mon, May 06, 2002 at 10:53:11AM +1000, Damian Conway wrote:
> Allison asked:
>
> > Hmmm... would C not have the same problem as C? It also
> > "can't decide whether to execute until it knows whether the loop is
> > going to iterate again".
>
> Yes, it does.
Then I agree with Miko, it's not
- Original Message -
From: "David Whipp" <[EMAIL PROTECTED]>
> Is this the same as saying that C can be followed by
> *any* statement? If not, then we would need user-defined
> control statements (a property on a sub?) that can be used
> in the "else" context.
Perhaps C is a binary operat
Oh. Sorry. I suppose there was no discussion because there were no
objections. I support it strongly. But everyone's already heard my
opinion, and my opinion, and my opinion about it, so I'll be quiet now.
Luke
On 6 May 2002, Aaron Sherman wrote:
> It's odd, folks are still talking about the
Miko O'Sullivan [mailto:[EMAIL PROTECTED]] wrote:
> Sorry, I thought I'd expressed agreement at some point. I like the
> "else\s+(if|while|for|loop)" construct very much, and I think the
> programmers of the world would like it too. I know a some people have
> issues with "where's the if" but it
> It's odd, folks are still talking about the icky elsstuff, but I never
> saw any discussion of my BNF proposal. Was it that no one saw it, that
> my BNF was too rusty, or the idea of abandoning elsif for (in
> pseudo-ebnf)
Sorry, I thought I'd expressed agreement at some point. I like the
"els
On Mon, 2002-05-06 at 12:22, [EMAIL PROTECTED] wrote:
> |Oh! I have an idea! Why don't we make the lexer just realize a prefix
> |"els" on any operator. Then you could do C. :P
> |
> |My point is that, IMO, this whole "els" thing is completely preposterous.
> |I'm the kind of person that likes t
On Mon, 6 May 2002 [EMAIL PROTECTED] wrote:
> |> Damian, now having terrible visions of someone suggesting C ;-)
> |
> |Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
>
> ]- unlessdo, unlesdont, unlessgrep, unlesstry
What's with this? unless doesn't do that,
perfect... in fact during the middle of the read someting similar come to my mind..
i.e the best way should be to have several in-loop-proprietes that we can test and
decide what to do ...
There have to be CAPITALISED words only for the block stuff ...
raptor
|> Damian, now having terrible visions of someone suggesting C ;-)
|
|Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
]- unlessdo, unlesdont, unlessgrep, unlesstry
what about "elsunless/unlesselse" then :")
|On Mon, Apr 29, 2002 at 02:55:09PM -0500, Allison Randal wrote:
|> I still don't like the idea of Cs on loops. I already do an
|> instant double take with C of "Where's the if?" (with visions of
|> old Wendy's commercials dancing in my head).
|
|Me too. That's why the looping "else" should be s
|Oh! I have an idea! Why don't we make the lexer just realize a prefix
|"els" on any operator. Then you could do C. :P
|
|My point is that, IMO, this whole "els" thing is completely preposterous.
|I'm the kind of person that likes to keep down on keywords. And I never
|liked Perl5's C anyway; I
Glenn Linderman wrote:
> I've been watching this "Loop controls" thread with much interest. It
> is clear that there is some convenience in the concept of specialized
> blocks that execute FIRST or LAST or NEXT and BETWEEN has a large
> appeal, considering the
Mike Lambert asked:
>
> > It's also unnecessary. The Holy Scoping Rules actually work in your favour in
> > this case. In Perl 6 you can just do this:
> >
> >
> > while my $cond = blah() {
> > ...
> > }
> >
> > and C<$cond> is defined *outside* the block.
>
> Question t
Allison asked:
Hmmm... would C not have the same problem as C? It also
> "can't decide whether to execute until it knows whether the loop is
> going to iterate again".
Yes, it does.
Damian
Miko O'Sullivan wrote:
> > Acme::Don't - The opposite of `do'
>
> Wonderful job, Damian! I'll get to work on the complementary Acme::TryNotTo
> module.
use Yoda;
do {...} or not do {...};
not defined try {...};
;-)
Damian
PS: that's valid Perl 6!
" (a
> name that implies it executes "between" each loop, not at the beginning
> of some).
>
> Hmmm... would C not have the same problem as C? It also
> "can't decide whether to execute until it knows whether the loop is
> going to iterate again".
> It's also unnecessary. The Holy Scoping Rules actually work in your favour in
> this case. In Perl 6 you can just do this:
>
>
> while my $cond = blah() {
> ...
> }
>
> and C<$cond> is defined *outside* the block.
Question then. Does the following code compile?
while
On Fri, May 03, 2002 at 11:13:45AM -0700, David Whipp wrote:
> Damian Conway wrote:
> > BUGS
> > Unlikely, since it doesn't actually do anything. However,
> > bug reports and other feedback are most welcome.
>
> Bug:
>
> don't { die } unless .error;
>
> doesn't DWIM (though the curre
From: "David Whipp" <[EMAIL PROTECTED]>
> don't { die } unless .error;
Whoa. This don't thing is starting to look eerily useful. Shades of the
Parrot parody.
-Miko
Damian Conway wrote:
> BUGS
> Unlikely, since it doesn't actually do anything. However,
> bug reports and other feedback are most welcome.
Bug:
don't { die } unless .error;
doesn't DWIM (though the current behavour, "do nothing", is
logically correct).
Dave.
> Um... I know it's scary, but I can actually imagine using this (or
> something like this) in development. I'll occasionally work on a section
> of code I'm not ready to integrate yet. It would be nice to be able to
> syntax check it without uncommenting and re-commenting the whole thing.
> :)
Y
On Wed, 2002-05-01 at 18:47, Damien Neil wrote:
> On Wednesday, May 1, 2002, at 02:27 PM, Aaron Sherman wrote:
> > unless my $fh = $x.open {
> > die "Cannot open $x: $!";
> > } else while $fh.getline -> $_ {
> > print;
> > } else {
> > die "No lines
On Wednesday, May 1, 2002, at 02:27 PM, Aaron Sherman wrote:
> unless my $fh = $x.open {
> die "Cannot open $x: $!";
> } else while $fh.getline -> $_ {
> print;
> } else {
> die "No lines to read in $x";
> }
I think you need a bet
On Wed, May 01, 2002 at 05:08:14PM -0400, Miko O'Sullivan wrote:
> Damian said:
> > The C block can't decide whether to execute until
> > it knows whether the loop is going to iterate again. And it can't
> > know *that* until it has evaluated the condition again. At which
> > point, the $filename
I now realize that my previous message was a little hard to read (plus I
sounded a bit harsh, which I did not mean to be, I was just excited,
thinking about this), because I insisted on being sort of stilted in my
pseudo-BNF. Here's a cleaner shot at what I meant:
flow:
co
Damian said:
> The C block can't decide whether to execute until
> it knows whether the loop is going to iterate again. And it can't
> know *that* until it has evaluated the condition again. At which
> point, the $filename variable has the wrong value. :-(
>
> The example is a little contrived per
On Wed, May 01, 2002 at 02:47:56PM -0400, Aaron Sherman wrote:
> On Wed, 2002-05-01 at 12:22, Allison Randal wrote:
>
> > You also avoid totally annoying Pythonists who occasionally use (and
> > might be converted to) Perl. :)
>
> ...
>
> Perl is fundamentally different in its approach and jus
On Wed, 2002-05-01 at 12:22, Allison Randal wrote:
> On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote:
[... in python ...]
> > while_stmt ::= "while" expression ":" suite
> > ["else" ":" suite]
> >
> > That's straight from http://www.python.org/doc/curre
On Wed, 2002-05-01 at 08:27, Miko O'Sullivan wrote:
> Damian said:
> > 6. C would seem to fit the bill rather nicely.
>
>
> To me, "otherwise" is a synonym for "else", and that makes it too
> confusingly similar. I foresee forever explaining to people the difference
> between C and C. I'm
On Wed, May 01, 2002 at 12:53:39PM -0400, Melvin Smith wrote:
> At 11:44 AM 5/1/2002 -0500, Allison Randal wrote:
> >
> >Um... I know it's scary, but I can actually imagine using this (or
> >something like this) in development. I'll occasionally work on a section
> >of code I'm not ready to integr
At 11:44 AM 5/1/2002 -0500, Allison Randal wrote:
>On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote:
> >
> > NAME
> > Acme::Don't - The opposite of `do'
> >
> > DESCRIPTION
> ...
> >
> > Note that the code in the `don't' block must be syntactically valid
> > Perl. Th
On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote:
>
> NAME
> Acme::Don't - The opposite of `do'
>
> DESCRIPTION
...
>
> Note that the code in the `don't' block must be syntactically valid
> Perl. This is an important feature: you get the accelerated performance
>
On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote:
>
> Hmm. I wonder why the python community (apparently) have no problems
> with elses on loops:
>
> 7.2 The while statement
>
> The while statement is used for repeated execution as long as an
> expression
On Wed, May 01, 2002 at 04:14:49PM +0100, Dave Mitchell wrote:
> In the true sprirt of perverseness, why not make loops into functions that
> return the number of iterations taken. Then you can have
>
> loop {
>
> }
> or die "loop not taken\n";
>
> ;-)
Right. This was my
In the true sprirt of perverseness, why not make loops into functions that
return the number of iterations taken. Then you can have
loop {
}
or die "loop not taken\n";
;-)
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999
Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Miko O'Sullivan wrote:
> > Damian said:
> > > 6. C would seem to fit the bill rather nicely.
> >
> > To me, "otherwise" is a synonym for "else", and that makes it too
> > confusingly similar. I foresee forever explaining to people the differen
Jonathan said:
> I actually think exactly the opposite. In my mind "otherwise" would
> just be a synonym for "else" so that
>
> loop { ... } else { ... }
> loop { ... } otherwise { ... }
>
> would both be syntactically valid.
I believe that the intention is that they *aren't* synonyms, i.e. they
On Wed, May 01, 2002 at 04:58:27PM +1000, Damian Conway wrote:
> 6. C would seem to fit the bill rather nicely.
I agree, but I'll also toss out a few alternates anyway:
instead
inlieu
orelse loop { ... } orelse { ... } reads nicely to me :-)
On Wed, May 01, 2002 at 08:27:41AM -0400, Miko O'Sullivan wrote:
> Damian said:
> > 6. C would seem to fit the bill rather nicely.
>
> To me, "otherwise" is a synonym for "else", and that makes it too
> confusingly similar. I foresee forever explaining to people the difference
> between C an
Damian posted:
> NAME
> Acme::Don't - The opposite of `do'
Wonderful job, Damian! I'll get to work on the complementary Acme::TryNotTo
module.
:-)
-Miko
Damian Conway wrote:
>Luke Palmer wrote:
>
>>Ooh! Why don't we have a dont command! With several variants:
>>dont FILE
>>dont BLOCK
>>
>>dont { print "Boo" }
>>
>>Would print:
>>
>>
>
>You really *should* be more careful what you wish for Luke.
>The following was just uploaded to
Damian said:
> 6. C would seem to fit the bill rather nicely.
To me, "otherwise" is a synonym for "else", and that makes it too
confusingly similar. I foresee forever explaining to people the difference
between C and C. I'm not sure if C is popular
because it is similar to C, but I think t
Luke Palmer <[EMAIL PROTECTED]> writes:
> On Tue, 30 Apr 2002, Miko O'Sullivan wrote:
>
>> > Damian, now having terrible visions of someone suggesting C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
>
> Ooh! Why don't we have a dont command! With several
Luke Palmer wrote:
> I'd rather have an in-betweener block too. Loops like this are very
> common, and I hate doing "prefix" commas, if you know what I mean. I
> realize NEXT often used for cleanup, so maybe you could introduse Yet
> Another block, BETWEEN (or SQUEEZE).
>
> Or are we just going
ralph wrote:
> I'm basically sold on Damian's conclusions. On the other
> hand the 'otherwise' clause still feels to me like a CAPITALS
> block.
>
> So, as a tweak, I suggest:
>
> while condition() {
> ...
> }
> NONE {
> ...
> }
Would you also change C to
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> > Damian, now having terrible visions of someone suggesting C ;-)
>
> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
To quote from the INTERCAL manual (and I doubt I'm the first to steal
features from that powerful lan
So, after all our discussions, my thinking regarding alternate blocks for
loops is now running like this:
1. It would definitely be useful to be able to catch the failure of a
block to iterate.
2. This ability should be available for all three types of block: C,
C, and C.
Luke Palmer wrote:
> Ooh! Why don't we have a dont command! With several variants:
> dont FILE
> dont BLOCK
>
> dont { print "Boo" }
>
> Would print:
>
>
You really *should* be more careful what you wish for Luke.
The following was just uploaded to the CPAN...
Damian
-c
Lots of people said:
>Lots of stuff about 'else' loops.
*Erik thunks himself some deep thought*
I see no true slippery slope here, especially if handled correctly. I suspect that an
explicit or implicit "why not" near the beginning of discussion lead to the feature
feeding frenzy and the slipp
Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
>
> Has anyone brought up elselse or unlessunless yet?
>
and
On Tue, 30 Apr 2002, Jim Cromie wrote:
> so, assuming we have;
>
> print 'you gave me: @wordlist = ';# single quote - no interpolation
>
> for @words -> $it {
> print;
> FIRST { print '(' }# provisionally
> NEXT { print ',' }
> LAST {print ');' }
> }
> # and maybe
> els
so, assuming we have;
print 'you gave me: @wordlist = ';# single quote - no interpolation
for @words -> $it {
print;
FIRST { print '(' }# provisionally
NEXT { print ',' }
LAST {print ');' }
}
# and maybe
else {
print "();\n";
}
this yields:
you gave me: @wo
> Then if you want "else when" or "else do", you're all set. It's an easy
> change and there are no new keywords.
Agree with everything else you said. One minor question: how would "else
do" be different than "else"? do always does, doesn't it?
-Miko
In a message dated Tue, 30 Apr 2002, Luke Palmer writes:
> On Tue, 30 Apr 2002, Trey Harris wrote:
>
> > Why not allow C while still allowing C as a synonym,
> > preserving backwards compatibility while still allowing all these weird
> > and varied constructs people seem to have use for?
>
> Back
On Tue, 30 Apr 2002, Trey Harris wrote:
> Why not allow C while still allowing C as a synonym,
> preserving backwards compatibility while still allowing all these weird
> and varied constructs people seem to have use for?
Backwards compatability is pretty much a lost cause for Perl 6. You could
Why not allow C while still allowing C as a synonym,
preserving backwards compatibility while still allowing all these weird
and varied constructs people seem to have use for?
In any case, I don't really see why C necessarily implies all
these other cases, too. Maybe they're useful in the real w
On Tue, 2002-04-30 at 13:07, Miko O'Sullivan wrote:
> > Damian, now having terrible visions of someone suggesting C ;-)
>
> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
Aaron, trying hard not to be a crackpot, but getting the impression
that's now just a dream :-/
On Tuesday, April 30, 2002, at 01:22 PM, Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
> Has anyone brought
On Tue, 30 Apr 2002, Miko O'Sullivan wrote:
> > Damian, now having terrible visions of someone suggesting C ;-)
>
> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
Ooh! Why don't we have a dont command! With several variants:
dont FILE
dont BLOCK
do
> Damian, now having terrible visions of someone suggesting C ;-)
Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
:-)
-Miko
On Tue, Apr 30, 2002 at 12:53:32PM +1000, Damian Conway wrote:
> Allison wrote:
>
> > The answer is the same, in any case: "When the condition in the
> > C has a false value, when the list/array in the C is empty,
> > or when the condition (2nd expression) in the C is met on the first
>
> OK, will at least this statement still work as it does in Perl5?
No.
> Notice addition of parens.
which, as you surmise later, have no effect on scoping issues.
> If that changes, I for one will need to go rewrite virtually every script
> and library I maintain,
or let p52p6 do it
> In Perl 6 a lexical variable is scoped to the block in which it's
declared.
> Since C<$cond> is declared in the block *containing* the C and
C,
> it's scoped to that block. So you can use it inside the C's block,
> inside the C's block (assuming Larry allows such a construct), and
in
> the follo
Miko wrote:
> I don't know if we're talking about the same thing, but I live using loops
> that declare variables in the test, so please exegize me. Which of these
> lines, if any, would cause a compiler error or warning?
>
> while my $cond = blah() {
> ...
> }
> else {
> print
> and C<$cond> is defined *outside* the block. So if Larry were to allow
C
> on loops, you'd be able to write:
> [snip]
> Given how rarely this kind of thing is actually needed (I've *never* used
such
> a construct), I suspect that an explicit variable is adequate.
I don't know if we're talking a
Allison wrote:
> The answer is the same, in any case: "When the condition in the
> C has a false value, when the list/array in the C is empty,
> or when the condition (2nd expression) in the C is met on the first
^
> Two solutions to the problem of accessing 'what' returned false are:
>
> 1) don't allow it.
> 2) Alias the value of the while/loop/if conditional into a special
> variable.
>
> while( blah() ) {
> ..
> } else { print $COND; }
>
> It's ugly, but it works, and doesn't break the holy scoping r
> > > I can also think of some advantages to having the "else" within the
> > > scope of the loop.
> >
> > while alllines("/etc/passwd") -> $_ {
> > ...
> > } else {
> > die "/etc/passwd: $_";
> > }
>
> But the aliased value, $_, is restricted to the scope of th
On Mon, Apr 29, 2002 at 04:25:26PM -0700, Peter Scott wrote:
> At 01:55 PM 4/29/02 -0500, Allison Randal wrote:
> >
> >There will have to be a section of the training material devoted to
> >"When is a loop false?" (I like that perspective, it nicely unifies the
> >cases), but it should be a short
At 04:15 PM 4/29/02 -0500, Allison Randal wrote:
>On Mon, Apr 29, 2002 at 04:14:01PM -0400, Aaron Sherman wrote:
> >
> > Well then, I guess we should dump "elsif" from if too. After all, it
> > could all be done with nested blocks of if/else
>
>But C is different. You use it all the time. The
On 4/29/02 1:41 PM, "Luke Palmer" <[EMAIL PROTECTED]>
claimed:
> My point is that, IMO, this whole "els" thing is completely preposterous.
> I'm the kind of person that likes to keep down on keywords. And I never
> liked Perl5's C anyway; I always preferred C. I really
> don't understand what at
At 01:55 PM 4/29/02 -0500, Allison Randal wrote:
>On Mon, Apr 29, 2002 at 10:10:01AM -0400, Aaron Sherman wrote:
> > Again, it's just first derivative over time. You're not asking "is there
> > a false value", you're asking "is the loop false". Just as we understand
> > that an array in a conditio
Allison wrote:
> I still don't like the idea of Cs on loops. I already do an
> instant double take with C of "Where's the if?" (with visions of
> old Wendy's commercials dancing in my head). It seems that a long string
> of Cs (possibly separated by other long intervening sections of
> code) woul
The only reasonable way of doing loops is to use highly verbose syntax:
#!/usr/bin/perl
# sample while loop
As_Long_As[0] __(*&%$ $%&*)__
begin_statement_of_syntax
# 7 (spaces required)
while_percha
1 - 100 of 151 matches
Mail list logo
