> "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 o
At 01:20 PM 9/3/00 +1100, Damian Conway wrote:
>> Modulo some superpositional silliness,
>
>Hey! I resemble that remark!
>
>Damian
I guess this means we should expect a N'Yuk module some time in the future...
--
Peter Scott
Pacific Systems Design Technologies
>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)'
>
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 -Mstri
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
>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
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
> "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 val
>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 co
> "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
Damian Conway <[EMAIL PROTECTED]> writes:
>> Modulo some superpositional silliness,
>
> Hey! I resemble that remark!
And we love you for it.
--
Piers
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 a
>>> 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 re
> "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 = f
>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 o
> "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
> Modulo some superpositional silliness,
Hey! I resemble that remark!
Damian
>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.
die unless wantarray;
>It should be immune from having a scalar context pushed through from
>the caller and change the commas from a list seperator into the
> "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
>> "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();
>T
> "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>
Tom Christiansen writes:
> >Yes, but 'eval' has the semantics "run this code but don't let it play
> >any funny tricks on me, like dying or anything", where 'do {...} while'
> >has the semantics "a while loop that evaluates its condition at the
> >end". There's no obvious reason why 'return'
>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 bu
>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'
At 02:30 PM 8/31/00 -0500, Christopher J. Madsen wrote:
>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;
> >
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
>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, $defs
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 t
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; ... }; #
Jonathan Scott Duff writes:
> 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?
Well, I suppose that for consistency's sake they shou
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; .
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 a
>>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 out if a retval
isn't wanted (as i
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
>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
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
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
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 BLO
39 matches
Mail list logo