develooper Front page | perl.perl6.language | Postings from August 2006

Re: === and array-refs

Thread Previous | Thread Next
From:
David Green
Date:
August 16, 2006 15:55
Subject:
Re: === and array-refs
Message ID:
a06230933c108f16a813b@[172.27.1.7]
On 8/16/06, Charles Bailey wrote:
>This is where the "eternal" part starts to confuse me (not picking on
>your wording, but on the semantics).

I'll pick on the wording (wording should always be picked on -- not 
to be pedantic (OK, I like to be pedantic, but that's not the *only* 
reason!), but because it really is an advantage to develop 
terminology that's as precise and pretty as possible).

Maybe values can be considered "eternal", in some philosophical 
platonic sense, but variables certainly aren't (eventually your 
program will reach the end or the sun will explode or something). 
"Permanent", maybe...

>What happens if I insert the C<$aa = "Two"> before line 255?  In other
>words, can I rely on P6 to know at line 3 that there's an alias out
>there by which C<$a> _might_ change without assignment later (i.e. the
>guarantee that "$a and $b will remain the same unless you assign to
>one" might be violated)?

...but there's nothing permanent either really, because you can 
always change any variable you like, later on at line 255.  (Unless 
the variable is a constant, which is not the same thing as being 
immutable even though those words are fairly synonymous, i.e. yet 
more confusing terminology.)

What we're really talking about is action-at-a-distance: one variable 
changing its value because *something else* changed -- some other 
variable that was somehow "contained inside" the first one.

Not to be confused with changing some other variable that is really 
the same variable because they were bound together: $a:=$b.  Should I 
call that two variables (somehow "linked" or bound together)?  Or 
would it be better (easier, less confusing) to call it *one* variable 
that has two names?  (Still nothing to be described as "permanent" 
here, because I can always unbind them later on, and have $a and $b 
being two completely separate variables, right?)

I find myself tempted to talk in temporal terms to explain the issue, 
and that's a natural way to frame examples, but the language of 
examples doesn't seem to be that good for explaining the concepts. 
Whether stuff may or may not change isn't the point; what it comes 
down to is referring to a variable itself vs. evaluating it.


-David
Thread Previous | Thread Next

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About