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

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

Thread Previous | Thread Next
Sawyer X
April 22, 2018 08:45
Re: [perl #133109] push on scalar forbidden: why?
Message ID:
I'm currently in no position to have a long discussion on this so I'll
just provide the short answer.

We tried autoderef. We removed it. We are not returning it.

On 04/20/2018 12:09 AM, L A Walsh wrote:
> 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",
>           "values"
>       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
> because
> 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
> fail.
>    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
> is?

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