On Wed, 14 Aug 2002 15:40:35 -0600 (MDT), Luke Palmer wrote:
We could make arglists exactly equivilent to the way they're done in Perl 5,
which is a good way.
sub foo($a, $b, *@c) {...}
Would be exactly equivilent to Perl 5's
sub foo { my ($a, $b, @c) = @_; ... }
Since
On Wed, 14 Aug 2002, Luke Palmer wrote:
Why? We could make arglists exactly equivilent to the way they're done in
Perl 5, which is a good way.
sub foo($a, $b, *@c) {...}
Would be exactly equivilent to Perl 5's
sub foo { my ($a, $b, c) = _; ... }
I've got another idea.
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
: I've got another idea. How about using a copy-restore technique?
I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Larry
On Thu, 15 Aug 2002, Larry Wall wrote:
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
: I've got another idea. How about using a copy-restore technique?
I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Yes and no.
For the normal case (pass-by-value semantics), it
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
On Thu, 15 Aug 2002, Larry Wall wrote:
On Thu, 15 Aug 2002, Deven T. Corzine wrote:
: I've got another idea. How about using a copy-restore technique?
I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Yes and no.
Uri Guttman wrote:
[ CCs stripped ]
... what if you passed \$a{llama}{alpaca}? even as a read only param,
you could deref later through the ref in another sub that gets passed it
from this sub.
If I understand Dan's proposal (a05111b55b977c7a65606@[63.120.19.221])
for a change in the
From: Larry Wall [EMAIL PROTECTED]
Perhaps there should be a way
to declare a parameter to be pass-by-value, producing a
modifiable variable that does not affect the caller's value.
But I'm not sure saving one assignment in the body is worth
the extra mental baggage.
and later he
[EMAIL PROTECTED]:
# Resolution: Use whatever default seems good, but provide the
# freedom to get pass-by-value-modifiable, perhaps something like this:
#
# sub mysub ($name is m, $email is m) { ... }
Of course! This *is* Perl after all--did you ever doubt that we would
give you all
From: Larry Wall [EMAIL PROTECTED]
The default is pass-by-reference, but non-modifiable. If
there's a pass-by-value, it'll have to be specially requested
somehow.
This is a minimal difference from Perl 5, in which everything
was pass-by-reference, but modifiable. To get pass-by-value,
Luke Palmer wrote:
Since variables are copy-on-write, you get the speed of
pass-by-reference with the mutability of pass-by-value,
which is what everyone wants. If you have this, why would
you want to do enforced const reference? That's not
rhetorical; I'm actually curious.
One reason I
On Mon, 5 Aug 2002, Dan Sugalski wrote:
At 1:30 PM +1000 8/6/02, Damian Conway wrote:
Luke Palmer asked:
Does:
print %foo{bar}{baz};
still create %foo{bar} as a hashref if it doesn't exist?
It is my very strong hope that it will not.
Unless Larry declares otherwise, it
On Tue, 13 Aug 2002, Deven T. Corzine wrote:
: However, will the func($x{1}{2}{3}) case cause an implementation problem?
This is why the new function type signatures will assume that
parameters are constant. If you want a modifiable parameter, you
have to say is rw. Then it's considered an
From: Larry Wall [EMAIL PROTECTED]
Of course, there are issues here if the code modifies those
variables, since the issue of whether a variable is rw is
really distinct from whether it represents a pass by value
or reference. Slapping a constant on it is a bald-faced
attempt to get the
On Tue, 13 Aug 2002, [EMAIL PROTECTED] wrote:
: From: Larry Wall [EMAIL PROTECTED]
: Of course, there are issues here if the code modifies those
: variables, since the issue of whether a variable is rw is
: really distinct from whether it represents a pass by value
: or reference. Slapping a
On Tue, 13 Aug 2002, Larry Wall wrote:
On Tue, 13 Aug 2002, Deven T. Corzine wrote:
: However, will the func($x{1}{2}{3}) case cause an implementation problem?
This is why the new function type signatures will assume that
parameters are constant. If you want a modifiable parameter, you
On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote:
The only accurate way to know if the code modifies the variables is to do
some sort of dataflow analysis, and it can't be 100% accurate even then.
(Suppose a shift may or may not happen, depending on the parameters, then
On Tue, 13 Aug 2002, Nicholas Clark wrote:
On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote:
The only accurate way to know if the code modifies the variables is to do
some sort of dataflow analysis, and it can't be 100% accurate even then.
(Suppose a shift may or may
NC == Nicholas Clark [EMAIL PROTECTED] writes:
NC Well, perl5 does already manage to avoid auto-vivifying hash keys
NC when they are used as subroutine arguments. It uses magic, rather
NC than dataflow analysis:
NC sub rval {
NC my $a = $_[0];
NC }
NC sub lval {
NC $_[0] =
18 matches
Mail list logo
