Re: RFC 127 (v1) Sane resolution to large function returns
I'm missing what you are trying to say. Are you suggesting that $foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ? I wasn't suggesting going that far. Just a little more DWIM. So that ($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef # or # $foo = 1 @bar=(2), $baz = 3 ($foo, @bar, $baz) = (1,(2,3),4) # $foo = 1 @bar=(2,3), $baz = 4 But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) *blech*, I'm glad that you're doing the thinking. chaim "LW" == Larry Wall [EMAIL PROTECTED] writes: LW Chaim Frenkel writes: LW : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW : LW context, as long as the object returned overloads itself to behave as LW : LW arrays and hashes currently do in scalar context. LW : LW : Isn't this an internals issue? LW Not completely. The scalar value would visably be a built-in object: LW @bar = (0,1,2); LW $foo = @bar;# now means \@bar, not (\@bar)-num LW print ref $foo, $foo-num, $foo-str, ($foo-bool ? "true" : "false"); LW ^D LW ARRAY3(0,1,2)true LW One implication of this approach is that we'd break the rule that says LW references are always true. Not clear if that's a problem. It's basically LW already broken with bool overloading, and defined still works. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 127 (v1) Sane resolution to large function returns
At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't that be $baz = 3, since the middle list would be taken in scalar context? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 127 (v1) Sane resolution to large function returns
Dan Sugalski [EMAIL PROTECTED] writes: At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't that be $baz = 3, since the middle list would be taken in scalar context? Which has sanely become the length of the list rather than last element. -- Nick Ing-Simmons
Re: RFC 127 (v1) Sane resolution to large function returns
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Dan Sugalski writes: LW : And do we want to consider making this (and its ilk) Do The Right Thing? LW : LW :(@foo, @bar) = (@bar, @foo); LW We certainly want to consider it, though perhaps not in -internals. LW You can talk about passing @bar and @foo around as lazy lists, and LW maybe even do lazy list-flattening, but I don't see how that works yet, LW even in the absence of overlap. The basic issue here may come LW down to whether the LHS of an assignment can supply a prototype for the LW entire assignment that forces everything to be treated as objects LW rather than lists. LW That is, right now, we can only have a scalar assignment prototype of ($), LW and a list assignment prototype of (@). We need a prototype (not just LW for assignment) that says "all the rest of these arguments are objects", LW so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@). LW Or (\@*) for short. Isn't that what Damian's named (whatever, formerly known as prototypes) does? @_ in the absence of a named argument list would continue to act _as if_ the argument list were flattened. With a named argument list, it would make the actual refs on the stack visible. The question that I think Dan proposed is how much breakage would infering (@foo, @bar) = (@bar, @foo) to mean treat RHS as objects, cause. Wouldn't having and @ anywhere but the last position in the list would be a useful indicator. I can see someone (Probably Randal or Tom) wanting to initialize a list that way. But for the rest of us, it isn't that useful. LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW context, as long as the object returned overloads itself to behave as LW arrays and hashes currently do in scalar context. Isn't this an internals issue? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 127 (v1) Sane resolution to large function returns
Chaim Frenkel writes: : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar : LW context, as long as the object returned overloads itself to behave as : LW arrays and hashes currently do in scalar context. : : Isn't this an internals issue? Not completely. The scalar value would visably be a built-in object: @bar = (0,1,2); $foo = @bar;# now means \@bar, not (\@bar)-num print ref $foo, $foo-num, $foo-str, ($foo-bool ? "true" : "false"); ^D ARRAY3(0,1,2)true One implication of this approach is that we'd break the rule that says references are always true. Not clear if that's a problem. It's basically already broken with bool overloading, and defined still works. Larry
Re: RFC 127 (v1) Sane resolution to large function returns
Dan Sugalski writes: : And do we want to consider making this (and its ilk) Do The Right Thing? : :(@foo, @bar) = (@bar, @foo); We certainly want to consider it, though perhaps not in -internals. You can talk about passing @bar and @foo around as lazy lists, and maybe even do lazy list-flattening, but I don't see how that works yet, even in the absence of overlap. The basic issue here may come down to whether the LHS of an assignment can supply a prototype for the entire assignment that forces everything to be treated as objects rather than lists. That is, right now, we can only have a scalar assignment prototype of ($), and a list assignment prototype of (@). We need a prototype (not just for assignment) that says "all the rest of these arguments are objects", so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@). Or (\@*) for short. Though if we let @foo and %bar automatically return refs in a scalar context rather than booleans, we might write that as (;$). ($*) for short. (Presuming * to be available if typeglobs go away.) However we force non-flattening object lists in prototypes, there's still the question of how you specify the use of an object list prototype on assignment. Hmm. (@foo, @bar) \= (@bar, @foo); Dunno if I like that or not. Larry P.S. I think we *could* let @foo and %bar return an object ref in scalar context, as long as the object returned overloads itself to behave as arrays and hashes currently do in scalar context. Larry
