Front page | perl.perl5.porters |
Postings from January 2001
In article <14937.21076.387073.251959@soda.csua.berkeley.edu>,
Stephen McCamant <smcc@CSUA.Berkeley.EDU> writes:
>>>>>> "TH" == Ton Hospel <perl5-porters@ton.iguana.be> writes:
>
> TH> Right (didn't know that until you and graham pointed that
> TH> out). The essence seem to be we have *two* "lvalue" concepts:
> TH> 1) Something we can assign to
> TH> 2) Something we can get hold of (through a container) and so
> TH> manipulate
>
> Yes; this is the distinction I was trying to make in a complicated way
> in another message. (I would call (1) a `syntactic lvalue' and (2) a
> `modifiable SV').
>
> TH> It has to be decided which one of these two meanings we should use
> TH> Or maybe we should just make them the same concept, i.e., make
> TH> things like this work:
>
> TH> sub fun {
> TH> shift()=5;
> TH> }
>
> This makes some sense, especially from the point of view of
> consistency. Taken to the logical extreme, though, it starts to look a
> little weird. For instance:
>
> ++$x = 10;
> $x++ = 10;
> shift(@x) = 5;
> getpwuid($<) = "smcc";
> "Hello, $user" = "greeting";
> $x + 2 = 7;
>
> These are all `assignments' that you might want to allow for
> consistency, since there's a corresponding assignment through a
> reference that goes through without an error. Except for the first,
> however, they're all no-ops. (It would be neat if the last set $x to
> 5, but that's a different feature).
>
> -- Stephen McC
Right. but we already have a concept to make the annoying ones not work:
read-only-ness:
perl -we '$a=\"fun"; $$a=3'
Modification of a read-only value attempted at -e line 1.
Thread Previous
|
Thread Next