develooper Front page | perl.perl5.porters | Postings from July 2013

Re: [perl #109744] referenced constant loses readonlyness

Thread Previous
July 31, 2013 16:16
Re: [perl #109744] referenced constant loses readonlyness
Message ID:
Father Chrysostomos via RT wrote:
>I'm not sure how to go about that, nor do I think it is necessary.  I
>always assumed that $a+$b would return a new mutable scalar, and that
>\($a+$b) just references a scalar that would otherwise have been
>short-lived.  Nothing in the observable behaviour contradicts that view.

If the behaviour is consistently thus, then we could document a general
principle that certain classes of operator generate new variables.
However, it's actually not a consistent behaviour of the addition
operator, because if the operands are sufficiently constant then
it gets constant folded and generates a read-only lvalue instead.
Related inconsistency is where this bug report started.

I think it is vitally important that we document which situations create
new variables, because it makes a real difference to the semantics
of reasonable programs.  If generating variables is a feature of the
language, then it is reasonable to use those variables by storing new
values in them.  If we have two references to variables, the program's
behaviour is likely to depend a great deal on whether they're distinct
variables or two references to the same variable.  The documentation
should provide enough information for someone using these variables to
determine which ones will be distinct.  Also, since addition doesn't
*always* generate a variable, the documentation must distinguish the
variable-generating cases from the read-only-lvalue cases.

>This bare value vs variable distinction is not something that is
>mentioned anywhere in the Perl documentation.

It's not necessary to cast the documentation in those terms.  It's a
useful abstraction in language design, but since Perl doesn't reify
the distinction it's not necessarily useful in documenting Perl.
In Perl the main concept is the scalar (or the broader concept of
scalar/array/hash/glob/etc.), which can always be referenced in an
lvalue way, so we never deal with values in isolation.  The important
distinction is between variable and read-only scalars, and among variables
the important feature is which operation created them (so that we can
determine which ones are separate storage locations).

>At this stage, I am willing to leave things inconsistent, as the changes
>I have made so far have allowed me to fix the bugs I wanted to fix.

OK, but we do need to document the behaviour.  Especially so if it's a
feature that we want to keep, but if not then we should at least say
something like "the scalar returned by this operation may be either
read-only or variable, and this may change in the future".


Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About