At 01:45 PM 9/4/00 -0600, Tom Christiansen wrote:
package main;
sub fn { return (3, 5, 7) }
tie $x, 'MaiTai';
$x = fn;
$ /tmp/foo
STORE: 7
Why don't I see three STOREs?
Because Perl is too clever to bother. :-)
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
three expressions separated by scalar commas. Why is there no complaint
about useless use of a constant in void context?
$ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()'
$ perl -Mstrict -wle 'my $x = (3,5,7)'
Damian Conway [EMAIL PROTECTED] writes:
Modulo some superpositional silliness,
Hey! I resemble that remark!
And we love you for it.
--
Piers
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Oh. You want lists to act like arrays. That's a very big change.
Do you have any objection? The intended avoidance of flattening to as
late as possible might have that effect.
You are letting the scalar context of the caller to bleed
Then please explain why scalar(return (1,2,3)) doesn't do what at first
glance it seems it should.
Because X(Y) != Y(X). You should have written "return scalar" if you
wanted to return a scalar.
And for the life of me I can't see how
$x=(1,2, (3,4,fn,6) )
fn ends up in scalar
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC You will be miserable until you learn the difference between
TC scalar and list context, because certain operators know which
TC context they are in, and return a list in contexts wanting a
TC list, but a scalar value in
At 06:49 AM 9/3/00 -0600, Tom Christiansen wrote:
sub fn { return (3,5,7) }
$x = fn;# I want $x==3
Why should it return the first one? It returns the last one!
It's just doing what you told it, which was:
$x = 3;
$x = 5;
$x = 7;
It does? What's
package main;
sub fn { return (3, 5, 7) }
tie $x, 'MaiTai';
$x = fn;
$ /tmp/foo
STORE: 7
Why don't I see three STOREs?
Because Perl is too clever to bother. :-)
--tom
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
I don't want to jam a list into anything. I want it to remain a list.
TC Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
TC A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
sub fn { return (3,5,7) }
$x = fn; # I
Think of it this way: you're asking that when you write
return WHATEVER;
(for various values of WHATEVER) that *sometimes* it's context
dependent, and sometimes it's not. Right now, it always is,
which is more consistent, predictable, and explainable than the
alternative.
Or maybe you're
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
It might be worthwhile enough to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
TC But this happens many places. What about @foo[4,1,9,-2]?
TC It's just a listish thing. One should learn.
I don't want that to change. I
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Well, that depends. Often you must delay till run-time. When Perl
TC simply sees something like:
TC sub fn { return @blah }
TC it can't know whether you'll use that as:
TC $x = fn();
TC or
TC @x = fn();
TC or
TC fn();
I
Likely this should be an RFC. I'm too lazy to write it in that format
right now, but I want to send this thing out before it slips my mind
again. Somebody else may pick it up, if he or she wants it. If not, I'll
eventually may have to do it myself.
The articial distinction between
do
At 11:38 AM 8/31/00 +0200, Bart Lateur wrote:
The articial distinction between
do BLOCK while condition;
and
EXPR while condition;
should go, because the former is nothing but a subcase of the latter.
Currently, the former executes the do BLOCK at least once, while the
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return value?
$x = TERM OP do { BLOCK } OP TERM;
Actually, these are all pretty similar in
On Thu, 31 Aug 2000 11:21:26 -0600, Tom Christiansen wrote:
One could argue that do{} should take return so it might have a value,
but this will definitely annoy the C programmers.
So what.
"Annoying" would be to have a situation that is *less* powerful in Perl
than in C, not *more*.
Oh, and
Tom Christiansen writes:
One could argue that do{} should take return so it might have a value,
but this will definitely annoy the C programmers.
So what.
So what is that it *already* annoys us, which is *why* we would like to
last out of a do. Perhaps you should be able to last
On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote:
I too would like to see last, next, redo work with do loops.
*Only* do loops or do blocks in general? And what should they do?
do { ... last; ... }; # exit the block immediately
do { ... next;
At 11:21 AM 8/31/00 -0600, Tom Christiansen wrote:
I want last, next, etc. to magically work where I want them to:
I too want last to work in do loops.
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return
Peter Scott writes:
I dunno, maybe a last in a do block whose value is used by
something should be a syntax error. We're talking about code like
$x += do { $y = get_num; last if $y == 99; $y } while defined $y;
right? *Shudder*
Yes, but we're also talking about code like
Tom Christiansen writes:
However, I really don't want to see 'return' become a kind of 'last'
for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don't let
22 matches
Mail list logo