Make native type and ref_to_native_type equivalent where ref_to_native_type is not a legal value

[Astara]

Make Explicit Sigil and Ref to Same, Equivalent
(where refs to a type are not legal values)

• Wherever the language currently requires a value of type Array or a value of type Hash will allow a reference to the same type.

• Any place where the language allows more than one type, will allow a reference to one of those allowed types.

Note: *This feature request excludes indeterminate behaviors. Also, this not the same as the previous "autoderef" feature, as it had been modified to allow overload operators associated with blessed packages. The original autoderef feature did not allow blessed packages and neither would this one. More than once I've asked when the change to allow blessed packages was inserted into the code (as it was the reason this feature was declared invalid), yet no one seemed to be able to point to the discussion where changing this to allow such references existed.

In any event, since this feature doesn't allow blessed packages, it cannot be used with overloading.

[leonerd]

I'm finding it quite hard to read through the wording in this request, to work out what feature you're actually asking for.

Could you perhaps provide some small perl code snippets (ideally in the form of a Test::More-based unit test or similar) that demonstrate what it is you want to do, but which isn't currently possible?

Maybe that would gain more traction.

[jkeenan]

Make Explicit Sigil and Ref to Same, Equivalent
(where refs to a type are not legal values)

* Wherever the language currently requires a value of type Array or a value of type Hash will allow a reference to the same type.

* Any place where the language allows more than one type, will allow a reference to one of those allowed types.

Note: *This feature request excludes indeterminate behaviors. Also, this not the same as the previous "autoderef" feature, as it had been modified to allow overload operators associated with blessed packages. The original autoderef feature did not allow blessed packages and neither would this one. More than once I've asked when the change to allow blessed packages was inserted into the code (as it was the reason this feature was declared invalid), yet no one seemed to be able to point to the discussion where changing this to allow such references existed.

In any event, since this feature doesn't allow blessed packages, it cannot be used with overloading.

I, too, found this feature request confusing. I grepped the core documentation and could find no instance of ref_to_native_type.

Thank you very much.
Jim Keenan

[leonerd]

Also, this not the same as the previous "autoderef" feature, as it had been modified to allow overload operators associated with blessed packages. The original autoderef feature did not allow blessed packages and neither would this one. More than once I've asked when the change to allow blessed packages was inserted into the code (as it was the reason this feature was declared invalid), yet no one seemed to be able to point to the discussion where changing this to allow such references existed.

I'm also not sure where this assertion comes from. At no point in the entire version history for which autoderef was a thing, has it ever accepted blessed refs.

$ perl5.14.4 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
Type of argument to keys on reference must be unblessed hashref or arrayref at -e line 1.

$ perl5.16.3 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
Type of argument to keys on reference must be unblessed hashref or arrayref at -e line 1.

$ perl5.18.2 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
Type of argument to keys on reference must be unblessed hashref or arrayref at -e line 1.

$ perl5.20.3 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
keys on reference is experimental at -e line 1.
Type of argument to keys on reference must be unblessed hashref or arrayref at -e line 1.

$ perl5.22.2 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
keys on reference is experimental at -e line 1.
Type of argument to keys on reference must be unblessed hashref or arrayref at -e line 1.

$ perl5.24.4 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj'
Experimental keys on scalar is now forbidden at -e line 1.

It was removed at 5.24 because it was felt the postfix-deref syntax was better. This works unambiguously on the actual container type, so is fine for both unblessed and blessed references alike.

$ perl5.24.4 -E 'my $href = {one=>1, two=>2}; say for sort keys $href->%*'
one
two

$ perl5.24.4 -E 'my $obj = bless {one=>1, two=>2}, "Object"; say for sort keys $obj->%*'
one
two

[karenetheridge]

No one has linked to the previous closed issue on this subject -- #18518 -- which I think is necessary for context and background information.

also the p5p thread: https://www.nntp.perl.org/group/perl.perl5.porters/2021/02/msg258964.html

[Astara]

@leonard -- the claim was made that the previous syntax allowed use of overloaded references. How is that possible unless the references were blessed? That the previous (or this) syntax did not work and had ambiguities was the reason stated for removing the previously working syntax.

The old syntax could be used, more concisely and with fewer characters than the new syntax. Ex:

> perl5.16.3 -MP -e'my $href = {one=>1, two=>2}; P for sort keys %$href;'
one
two

perl5.16.3 -MP -e'my $obj = bless {one=>1, two=>2}, "Object"; P for sort keys %$obj;'
one
two

What it doesn't work for is the simplest case:

> perl5.16.3 -MP -E'my $href = {one=>1, two=>2}; P for sort keys $href;'
 one
 two

This simple case only works for unblessed references, which was the original intention.

For those who don't understand that 'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal, and that 'ref_to_native_type' is a "reference to [the same] 'native_type'", use this as a guide:

• 'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal
• 'ref_to_native_type' is a "reference to [the same] 'native_type'"

The intent of this syntax was to simplify such references like:

• $href (a hash ref) being used in places where %$href is now required
  and
• $aref (an array ref) being used in places where @$aref is now required.

The type of a ref is already known by perl by using the building ''''ref'''' operator which returns ARRAY or HASH depending on the type of ref. It will not work (nor is it intended to work) on a blessed reference.

As near as I can tell there is no "failure" case as some have stated, and the "autoderef" experiment never included cases that failed (like allowing use of overloaded operators), because overloaded operators can only be used in the context of a package with a blessed reference.

The existing syntax allowed since 5.14 through 5.22 doesn't appear to have any problems with ambiguity. So far, no one has presented any evidence or reasons why it was removed, nor given any reason why post-ref operators should be added to a language that contains too many sigils when no other modern language supports or uses such syntax. Why introduce a more complicated syntax when the less complicated, simpler syntax worked fine?

As near as I can tell, the postfixsigil feature was implemented because, the autoderef syntax had problems, yet no one is able to state what or how those problems occurred or wouldn't, for that manner, exist in the postfix syntax.

[leonerd]

@leonard -- the claim was made that the previous syntax allowed use of overloaded references. How is that possible unless the references were blessed? That the previous (or this) syntax did not work and had ambiguities was the reason stated for removing the previously working syntax.

First off it's "@leonerd", not what you wrote.

Secondly, where has that claim been previously made? I don't recall making it myself, and I don't see anyone else having made it. Do you have a reference?

Have you checked the list threads I mentioned in reply on the mailing list? Specifically:

• https://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228318.html
• https://www.nntp.perl.org/group/perl.perl5.porters/2013/08/msg206464.html

Those all talked about the fact that postfix deref was deemed a better solution.

[leonerd]

For those who don't understand that 'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal, and that 'ref_to_native_type' is a "reference to [the same] 'native_type'", use this as a guide:

'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal
'ref_to_native_type' is a "reference to [the same] 'native_type'"

Some interesting notation. Did you document that previously where anyone else would be able to see it?

[leonerd]

The existing syntax allowed since 5.14 through 5.22 doesn't appear to have any problems with ambiguity. So far, no one has presented any evidence or reasons why it was removed, nor given any reason why post-ref operators should be added to a language that contains too many sigils when no other modern language supports or uses such syntax. Why introduce a more complicated syntax when the less complicated, simpler syntax worked fine?

As near as I can tell, the postfixsigil feature was implemented because, the autoderef syntax had problems, yet no one is able to state what or how those problems occurred or wouldn't, for that manner, exist in the postfix syntax.

Again I suggest going to read the mailing list archives. It was discussed there. I wasn't around at the time so I have no personal insight into the details; all I can do is read and quote things from public sources.

In any case, that all happened 6 or 8 years ago now.

[leonerd]

Ah; further discussion also on another mailing list thread linked from those ones, that I missed on my initial search because it has hyphenated "auto-deref":

https://www.nntp.perl.org/group/perl.perl5.porters/2013/11/msg209170.html

It would also appear I was around for at least some of the discussion, though I don't recall having much influence in the matter all the way back then.

[Grinnz]

On Fri, Feb 5, 2021 at 1:32 PM Paul Evans ***@***.***> wrote: Ah; further discussion also on another mailing list thread linked from those ones, that I missed on my initial search because it has hyphenated "auto-deref": https://www.nntp.perl.org/group/perl.perl5.porters/2013/11/msg209170.html

I would draw your attention specifically to https://www.nntp.perl.org/group/perl.perl5.porters/2013/11/msg209444.html as well as https://www.nntp.perl.org/group/perl.perl5.porters/2013/11/msg209460.html.

…

-Dan

[Astara]

It wasn't removed until 5.24, which didn't hit distros till at most, a few years ago. Time is funny, what you see as happening long ago, I see as a current issue, but like many in the outside world, I have been using earlier versions of perl. Regardless of the notes you provide from earlier discussions, be aware I was removed from the list for seven years. I could not be responsible or respond to any changes that occurred. Others who disagreed with the oligarch's also were censured and in some cases started supporting earlier versions or alternate versions of perl.

I don't put much stock in a perl developed in a closed environment or anything from 5.18 on. 5.18 added the forced warnings turned on, while the perl community, at the time, went against sound software practice in all other languages where fatal warnings were turned on by default. Warnings are a signal that something is wrong and that indeterminate behavior may result. They are a signal that the language has changed that may result in unpredictable behavior then or in the future. It's a security bug and disk-format potential all-in-one.

I remember being an advocate for simpler options for syntax, and to reduce unnecessary non-working cases to produce something useful.

As for the portions you quote, I see Ricardo claiming that the more complicated syntax was somehow better. By the measures of complexity and past understanding the new syntax was not better. Saying it is better without defining why or how it is better doesn't make it so. Ricardo was the pumpking and as such had dictator power to enact anything he wanted. No one spoke against him who wasn't told or forced to leave the community.

Someone else suggested a new syntax for "something" and one of the perl oligarch's asked what other languages had used such a construct that it should be adopted. I ask the same of the post-sigil syntax. Perl had a working syntax before that wasn't ambivalent, and was, most of all, simpler.

In the same way allowing printf FILE,"fmt", [vars] to work rather than emitting an error was suggested, as well as sprintf working with an array or list instead of a forced 'scalar', array. In both cases, perl produced or produces and error or something that doesn't work or is "almost* never useful". *-later I asked for cases to be included in the documentation where it was useful -- no one could think of any working code where it was used or useful. But I was told a warning message would be put in.

There were other examples where I asked for simplifications and one case where I suggested something that would have created an incompatibility, though no one could think of how it would arise. I later found it myself in my own testing -- but giving evidence to my premise that it was rarely used or done.

Besides those, I had other improvements, like removing the need for sigils where a variable of a unique name had been previously declared. So if you don't create the same variable name of different types, and you had them declared such that perl knew about them, you would be able to leave off sigils in a wide number of cases -- perhaps all cases where nothing fancy was being done. Javascript, which was derived from perl, demonstrates a sigil-less syntax that would be comparable in many cases.

Syntax that adds more sigils is not better by any computer language definition. Brevity and conciseness are hallmarks of a languages power -- allowing user to express more in less space, more quickly and with less work.

[Astara]

@leonerd wrote:

For those who don't understand that 'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal, and that 'ref_to_native_type' is a "reference to [the same] 'native_type'", use this as a guide:

'native_type' is a "native type" -- specifically ARRAY or HASH in this proposal
'ref_to_native_type' is a "reference to [the same] 'native_type'"

Some interesting notation. Did you document that previously where anyone else would be able to see it?

---

Funny. I documented it as soon as someone claimed not to understand the notation, not before. I didn't realize how complicated such notation was until questioned about it.

[karenetheridge]

I didn't realize how complicated such notation was until questioned about it.

It's always more complicated when you get into details. When digging deeper, one encounters edge cases that were not initially obvious.

We await some code demonstrating the effects of changes you request, as per #18532 (comment).