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

[perl #109744] referenced constant loses readonlyness

Thread Previous
From:
Father Chrysostomos via RT
Date:
August 12, 2013 20:49
Subject:
[perl #109744] referenced constant loses readonlyness
Message ID:
rt-3.6.HEAD-2552-1376340563-1631.109744-15-0@perl.org
On Wed Jul 31 09:17:27 2013, zefram@fysh.org wrote:
> 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.

Actually, I fixed that in commit 2484f8dbbb.

> 
> 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.

The only inconsistency left here is in constant.pm, and I documented it
in 842f3911b.

> 
> 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".

How does the attached patch look to you?

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=109744

Thread Previous


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