Peter Scott writes:
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
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)'
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS I find myself wishing there were something we could do about the
PS context rules. They seem simple enough, individually, but when
PS you put them together - well, there was a quiz a year or so ago -
PS I forget whether it was in TPJ or Usenet -
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
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 that to change. I simply want that return (I'm not sure
how to phrase this) be able to return only a scalar or an aggregate.
TC die unless wantarray;
Okay, I'll admit it, again. I find the changing of a comma in what
looks like
I don't want to jam a list into anything. I want it to remain a list.
Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
sub fn { return (3,5,7) }
$x = fn;# I want $x==3
Why should it return the first
"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
sub fn { return (3,5,7) }
$x = fn;# I want $x==3
Let me try once more. I want that fn() to act like
sub fn { my @a = (3,5,7); return @a}
Oh. You want lists to act like arrays. That's a very big change.
You are letting the scalar context of the caller to bleed through the return
and
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
Modulo some superpositional silliness,
Hey! I resemble that remark!
Damian
"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
"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
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
AFAICT we could make it a syntax error iff foo is not used in void context;
Perl must be able to tell whether or not it is used in order to know what
context the result is in, right?
Well, that depends. Often you must delay till run-time. When Perl
simply sees something like:
sub fn {
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
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.
But I while I am not completely bothered by letting the value
dangle here:
($msg,
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:
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
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
On Thu, Aug 31, 2000 at 02:13:23PM -0500, Christopher J. Madsen wrote:
Jonathan Scott Duff writes:
do { ... last; ... }; # exit the block immediately
do { ... next; ... }; # equivalent to last?
do { ... redo; ... }; #
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
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
29 matches
Mail list logo
