Front page | perl.perl5.porters |
Postings from April 2018
Re: [perl #133109] push on scalar forbidden: why?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
April 22, 2018 08:45
Subject:
Re: [perl #133109] push on scalar forbidden: why?
Message ID:
5a779934-643a-747e-e5d6-c8c5cba992d9@gmail.com
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