> "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
38 matches
Mail list logo
