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 become
# $foo=1
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 to
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++...
:
: For those who
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
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
#
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
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
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 passing
"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 become
# $foo=1
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
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()) {
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
: judge,
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 {
= ...
= if
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
Perl6 RFC Librarian writes:
There has been a proposed new core function Cwant(). 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
Cwant() internally to determine what to return i.e; a list or a hash.
As for single datum access, Iperhaps Cfunction-[index] or
Cfunction()-{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
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
18 matches
Mail list logo
