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
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, 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
In essence, all Perl 5 functions have a signature of (*@_ is rw).
Perhaps the translator can turn some of those into (*@_). What'd
really be cool is if it could pick up an initial
my ($a, $b, $c) = _;
Excuse my ignorance here, but I thought the plan for backwards
compatibility with
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] =
