Chaim Frenkel wrote:
> > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> GL> Chaim Frenkel wrote:
> >> ($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
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
GL> Chaim Frenkel wrote:
>> ($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)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> 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
Chaim Frenkel wrote:
> ($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)
Actually? How about it becoming
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
>>
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)
Woul
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> implicit references internally. Consider how you'd implement
LW> push(@foo, @bar);
LW> vs
LW> push(@foo, \@bar);
LW> If you defer the decision to flatten into the function, then you have
LW> to distinguish those two kinds of refe
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
# o
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
> "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
Dan Sugalski writes:
: Chicanery's on the big To Do list. I'm really wanting to defer list
: flattening as long as possible, and skipping it all together.
And I'm wondering whether it's better in general to explicitly force a
context in which we treat @foo and %bar as objects, rather than trying
At 08:02 AM 8/24/00 -0700, Larry Wall wrote:
>Bart Lateur writes:
>: On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>:
>: >> I expect that we'll get more compile-time benefit from
>: >>
>: >> my HASH sub foo {
>: >> ...
>: >> }
>: >>
>: >> %bar = foo();
>: >
>: >Ah, t
Bart Lateur writes:
: On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
:
: >> I expect that we'll get more compile-time benefit from
: >>
: >> my HASH sub foo {
: >> ...
: >> }
: >>
: >> %bar = foo();
: >
: >Ah, the Return Value Optimization so loved in C++...
: >
:
On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>> I expect that we'll get more compile-time benefit from
>>
>> my HASH sub foo {
>> ...
>> }
>>
>> %bar = foo();
>
>Ah, the Return Value Optimization so loved in C++...
>
>For those who haven't seen it before, you can
Larry Wall wrote:
>
> I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
Ah, the Return Value Optimization so loved in C++...
For those who haven't seen it before, you can optimize this by passing
in a reference to %bar
Buddha Buck <[EMAIL PROTECTED]> wrote:
=
=At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
=
=>I expect that we'll get more compile-time benefit from
=>
=> my HASH sub foo {
=> ...
=> }
=>
=> %bar = foo();
=
=So how would you fill in the type in:
=
=my TYPE sub foo {
= ...
=
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-flatt
At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: The core will already know.
>
>Especially if we add return types.
Sure. Can't hurt to add code to optimize 'old-style' perl 5 code either,
though.
>: Whether this justifies exposing the information's for someone else to
>: ju
Buddha Buck writes:
: At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
:
: >I expect that we'll get more compile-time benefit from
: >
: > my HASH sub foo {
: > ...
: > }
: >
: > %bar = foo();
:
: So how would you fill in the type in:
:
: my TYPE sub foo {
:...
:if (want
At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
>I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
So how would you fill in the type in:
my TYPE sub foo {
...
if (wanthash()) { return %bar; }
if (wantarray()) {
Dan Sugalski writes:
: The core will already know.
Especially if we add return types.
: Whether this justifies exposing the information's for someone else to
: judge, but the core will know what context something is in. This is for
: optimization reasons. While it's straightforward enough to k
At 12:17 PM 8/18/00 -0600, Nathan Torkington wrote:
>Perl6 RFC Librarian writes:
> > There has been a proposed new core function C. this seems
> > to be generally regarded as a good thing. Fine. If it is implemented
> > we should use it. Offending functions (See RFC 37) should use
> > C internally
Perl6 RFC Librarian writes:
> There has been a proposed new core function C. this seems
> to be generally regarded as a good thing. Fine. If it is implemented
> we should use it. Offending functions (See RFC 37) should use
> C internally to determine what to return i.e; a list or a hash.
This imp
> As for single datum access, I C[index]> or
> C{key}> should be considered. This however, is not the
> core of this proposal. Merely a possibility. Just as extending the
> inelegant metaphor above to C<{function()}->{key}> would become a
> possibility.
Personally, I think lists should always sta
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Sane resolution to large function returns
=head1 VERSION
Maintainer: Jerrad Pierce <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 127
=head1 ABSTRACT
Pe
25 matches
Mail list logo
