develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #133109] push on scalar forbidden: why?

Thread Previous | Thread Next
L A Walsh
April 19, 2018 22:09
Re: [perl #133109] push on scalar forbidden: why?
Message ID:
Sawyer X via RT wrote:
> Hi Linda,
> Whether there are situations that are unambiguous for the compiler or
> not, there are additional reasons to removing auto deref. This includes
> ambiguity for the developers as well - and even if that is arguable, the
> confusion for the developer isn't. Providing an auto deref for some
> operations but not others is far worse than supporting it in full.
> I think this ticket should be respectfully rejected.
    Might I ask, how it is confusing for a developer?  Most languages
have no typing indicator -- at least perl will flag an error if the
variable being dereferenced is of the wrong type:

perl -e 'my $a={};
push $a,1;'
Not an ARRAY reference at -e line 2.

    I'm not sure what you mean by providing for auto-deref in some
operations but not others.  It would be implemented in all operations
where NOT auto-dereferencing would be an error.

    How would that be unclear for a perl developer who probably
(right or wrong) knows what would be a syntax error and what would not
be.  It's an extension into an area that would previously have been
*unused* -- because all attempts to use invalid syntax, before, would
have been flagged with an error.

    But to make it easier, it looks like perfunc holds the answer.  It
lists functions that work on ARRAYS and functions that work on HASHes.

    I may have missed something, but the dereference feature would only
work where the language would require an ARRAY or a HASH.  If the language
requires an ARRAY or a HASH, the user would be able to supply that
with a literal ARRAY or HASH, OR a reference to an ARRAY or HASH.

    If you want to complain about it working in some places and not
others -- it's based on the fact that the language only allows
ARRAYs and HASHes in various locations. 

    The manpage shows:
       Functions for real @ARRAYs
           "each", "keys", "pop", "push", "shift", "splice", "unshift",

       Functions for real %HASHes
           "delete", "each", "exists", "keys", "values"

    As far as I can tell, these should be the entirety of functions
that have required a '@' or '%' as part of the syntax.  In those cases,
if a SCALAR holds a reference to an ARRAY or a HASH, then the undereferenced
scalar could be used without the need for adding extraneous characters 
perl knows (and will flag an error) if a scalar does or doesn't contain
a reference to the correct type.

    Similarly, the open call can take a scalar with a value of 'undef'
and can store a file reference in that scalar.  Whether or not that will
work is entirely dependent on the contents of that var -- if it contains
any other type of reference or value, it is specification says it should

    Similarly, in any location where an ARRAY or HASH is required,
that requirement can be satisfied only with a var of the correct type
whether it be literal or a reference.

    The feature was enabled for 2 years, and triggered
warnings for the next 3 years before it was removed for no reason that
I've been able to find out.  Even the release notes claim that it was
an experiment that "failed", but give no details about how or why it
failed only that it was replaced with an optional syntax. 

When one of the main complaints against perl (as being read by others or
others learning it) has been that it looks like 'line noise'.  Adding
postfix sigils in addition to the more concise prefix sigils that
were already there, seems like the wrong direction to go.  If anything,
perl should strongly think about going "sigil-optional" where there would
be no ambiguity(no vars of the same name and would require being
pre-defined or referenced), but that's somewhat of a different issue.

    I don't see this being some vague nebulous issue the way some
seem to be painting it.  In some discussions about this some expressed
what they were told -- that some things were ambiguous.  I really
wanted to see an ambiguous case, but so far, no one has been able
to present one (perhaps I didn't understand the extent to which
the original concept had been applied). 

    Perhaps Sawyer is thinking about something other than what this

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