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) = @_; ... }
>
> Si
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.
>
> Y
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:
: 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 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 anothe
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 reas
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-val
[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 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
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 ()
for a change in the KEYed methods correctly, this would wo
> "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 {
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" ma
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, 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,
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. Slappin
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 th
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
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 de
18 matches
Mail list logo
