Larry Wall wrote:
Still think if there's no invoices it logically should be tested first.
If you don't want to repeat mentioning the array, how 'bout:
@invoice or fail 'No invoices to process'
==> for @() {
.process
}
or equivalently
@invoice or fail 'No invoices to pro
On Mon, Mar 05, 2007 at 04:13:16PM +1030, Tom Lanyon wrote:
: Sounds like the following will work, but it doesn't seem 'nice'.
:
: for @invoice
: {
: .process;
: 1;
: } or fail 'No invoices to process';
Still think if there's no invoices it logically should be tested first.
If you don't want to
Larry Wall wrote:
Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping? (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other? It's just a topicalizer.
:
: One implication of repla
On Sun, Mar 04, 2007 at 09:44:59PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: >: Finally: when used as a statement modifier, is "given" considered to
: >: be conditional or looping? (Gut instinct: conditional.)
: >
: >Why does it have to be one or the other? It's just a topicalizer.
:
: O
Larry Wall wrote:
: Finally: when used as a statement modifier, is "given" considered to
: be conditional or looping? (Gut instinct: conditional.)
Why does it have to be one or the other? It's just a topicalizer.
One implication of replacing "statement_modifier" with
"statement_mod_cond" and
Larry Wall wrote:
On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: >On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: >: Rick Delaney wrote:
: >: >Smylers wrote:
: >: >> for @invoice
: >: >> {
: >: >> .process;
: >: >> } or fail 'No invoic
On Sun, Mar 04, 2007 at 09:38:05PM -0800, Larry Wall wrote:
: grammar and override the rules as you see fit. Macros and user-defined
s/user-defined/user-defined operators/
Larry
On Sun, Mar 04, 2007 at 09:25:31PM -0800, Jonathan Lang wrote:
: AFAICT, there's nothing in the documentation to explain how one would
: define a statement or operator with syntax along the lines of "if ...
: else ..." or "... ?? ... :: ..." Admittedly, the only cases I know of
: where this is sti
On Sun, Mar 04, 2007 at 08:55:28PM -0800, Jonathan Lang wrote:
: The text of S02, S03, and S04 still contain references to the
: now-defunct "statement_modifier" grammatical category.
Yes, there are several similar issues that need to be cleared up
as soon as http://svn.pugscode.org/pugs/src/perl6
On Mon, Mar 05, 2007 at 03:56:16PM +1030, Tom Lanyon wrote:
: Larry Wall wrote:
: >On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: >: Rick Delaney wrote:
: >: >Smylers wrote:
: >: >> for @invoice
: >: >> {
: >: >> .process;
: >: >> } or fail 'No invoices to process';
: >:
Larry Wall wrote:
On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: Rick Delaney wrote:
: >Smylers wrote:
: >> for @invoice
: >> {
: >> .process;
: >> } or fail 'No invoices to process';
: >
: >If that actually works then I'm happy.
:
: It's dependent on .process not ret
AFAICT, there's nothing in the documentation to explain how one would
define a statement or operator with syntax along the lines of "if ...
else ..." or "... ?? ... :: ..." Admittedly, the only cases I know of
where this is still an issue are the two listed above: for statements,
all other perl 5
On Sun, Mar 04, 2007 at 06:37:34PM -0800, Jonathan Lang wrote:
: Rick Delaney wrote:
: >Smylers wrote:
: >> for @invoice
: >> {
: >> .process;
: >> } or fail 'No invoices to process';
: >
: >If that actually works then I'm happy.
:
: It's dependent on .process not returning a false on th
The text of S02, S03, and S04 still contain references to the
now-defunct "statement_modifier" grammatical category.
Also, what's the reasoning behind specifically disallowing _all_
statement modifiers to "do" blocks (as opposed to forbidding just
looping statement modifiers)? Is this legacy fro
Rick Delaney wrote:
Smylers wrote:
> for @invoice
> {
> .process;
> } or fail 'No invoices to process';
If that actually works then I'm happy.
It's dependent on .process not returning a false on the final iteration.
--
Jonathan "Dataweaver" Lang
On Mar 04 2007, Smylers wrote:
> for @invoice
> {
> .process;
> } or fail 'No invoices to process';
If that actually works then I'm happy.
--
Rick Delaney
[EMAIL PROTECTED]
Steve Lukas writes:
> On the other hand, there is no important reason for it because C<
>
> for @rray -> $el {}
> if ! @rray {}
>
> >
> should work. It's short and easy to understand.
But it involves repeating C<@rray> -- which for more complex expressions
(results from function calls, delving
Steve Lukas schrieb:
> More exceptional rules in a language are bad in itself.
> Those exceptions force people to more to learn more stuff
I guess that most people would understand the for/empty(/start/end) code
without having ever written any line of Perl.
They won't understand first/Any/gather d
Andy Armstrong writes:
> On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
>
> > I'd like the For::Else behaviour more. Especially as I remember
> > numerous times writing an if clause to check if a list is empty
> > before processing it.
>
> That's crazy. If the list is empty foreach still does th
Daniel Brockman wrote:
What about this?
given @foo {
for $_ -> $x { ... }
when .empty { ... }
}
You can reverse the order if you want:
given @foo {
when .empty { ... }
for $_ -> $x { ... }
}
Actually, you'd be better off using the second order; the "when"
stat
What about this?
given @foo {
for $_ -> $x { ... }
when .empty { ... }
}
You can reverse the order if you want:
given @foo {
when .empty { ... }
for $_ -> $x { ... }
}
I don't like C<$_>, but I can't think of a way to get rid of it.
--
Daniel Brockman <[EMAIL P
I vote against this proposal.
More exceptional rules in a language are bad in itself.
Those exceptions force people to more to learn more stuff
and lead to confusion for those who don't know every detail
of this language. So, there should be an important reason
for that or it's a silly idea.
I
On 3 Mar 2007, at 00:39, Thomas Wittek wrote:
I'd like the For::Else behaviour more. Especially as I remember
numerous
times writing an if clause to check if a list is empty before
processing it.
That's crazy. If the list is empty foreach still does the right thing
- there's no benefit in
Darren Duncan schrieb:
> At 11:17 PM +0100 3/3/07, Thomas Wittek wrote:
>> Larry Wall:
>>> : if ($item = 'foobar') {
>>
>> == of course ;)
>>> If you actually wrote that, then you'll always find that the first
>> > item has the value 'foobar'. :)
>
> Care to try a third time?
>
> I don't
Jonathan Lang wrote:
Seconded. I would favor allowing an "else" block to be attached
following any loop block, with the semantics being that the else block
only gets triggered if the loop block doesn't run at least once. I'd
do this instead of a block trait (such as FIRST or LAST) because of
th
herbert breunung wrote:
> Von: Thomas Wittek <[EMAIL PROTECTED]>
> That's, well, elegant! Yes.
> Because and but it's tricky.
> Nothing where I'd say "wow, thats an easy solution to my problem!".
> It's a bit complicated, because you have to understand and combine
> several concepts. That's elega
> Von: Thomas Wittek <[EMAIL PROTECTED]>
> That's, well, elegant! Yes.
> Because and but it's tricky.
> Nothing where I'd say "wow, thats an easy solution to my problem!".
> It's a bit complicated, because you have to understand and combine
> several concepts. That's elegant. But not easy, I think
27 matches
Mail list logo
