Mailing List Archive

I don't see how you came to this conclusion.

Very simply, you are requesting a misfeatures. If you are writing a sub,
now you have to be defensive and check that the array-like thing that was
passed in isn't an object. You literally only gain bugs by subtly
disallowing Mojo::Collection objects to be passed in even though they are
INTENDED to be used as an array.

Your arguments about objects being opaque is also misled. Objects ARE
opaque, and therefore if they tell you that they can be used as an array,
it shouldn't matter if its blessed or not. The overloading IS part of its
interface.

On Sun, Feb 28, 2021, 09:21 L A Walsh <astara@tlinx.org> wrote:

> It seems all of the reasons against auto-deref were answered in-so-much
> that
> that claims of ambiguity were shown not to exist. For example, in
> the case of use of 'keys'. Without autoderef, the language requires
> a perlvar of type ARRAY or HASH with a '@' or a '%' in front of it.
> Autoderef only supported the option of having a reference to something
> that would have had an '@' or a '%' in front of it. Since perl always
> knows the type of vars having an '@' or '%' in front of, then
> a reference to either can automatically, and unambiguously always be
> assumed to be of type that would have had an '@' or '%'.
>
>
> So can I ask that it's removal be undone?
>
> Thanks!
>
>
>
>

On Sat, 27 Feb 2021 23:21:21 -0800
L A Walsh <astara@tlinx.org> wrote:

> It seems all of the reasons against auto-deref were answered
> in-so-much that
> that claims of ambiguity were shown not to exist. For example, in
> the case of use of 'keys'. Without autoderef, the language requires
> a perlvar of type ARRAY or HASH with a '@' or a '%' in front of it.
> Autoderef only supported the option of having a reference to something
> that would have had an '@' or a '%' in front of it. Since perl always
> knows the type of vars having an '@' or '%' in front of, then
> a reference to either can automatically, and unambiguously always be
> assumed to be of type that would have had an '@' or '%'.

This has been discussed aplenty on

https://github.com/Perl/perl5/issues/18532

I don't believe this email thread adds anything new to the subject.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sun, Feb 28, 2021, at 2:21 AM, L A Walsh wrote:
> It seems all of the reasons against auto-deref were answered in-so-much
> that that claims of ambiguity were shown not to exist. For example, in
> the case of use of 'keys'. Without autoderef, the language requires
> a perlvar of type ARRAY or HASH with a '@' or a '%' in front of it.
> Autoderef only supported the option of having a reference to something
> that would have had an '@' or a '%' in front of it. Since perl always
> knows the type of vars having an '@' or '%' in front of, then
> a reference to either can automatically, and unambiguously always be
> assumed to be of type that would have had an '@' or '%'.
>
> So can I ask that it's removal be undone?

The short answer is: this just isn't happening.

I think, but am not sure, that you're a bit confused about the realities of the ambiguity of autoderef. Some built-ins can work on both hashes and arrays. These include "keys" and "each" and "values". (I think that's it.) Also, via overloading, a reference may be able to function as both a hash and array reference. Consider this program:

use v5.14.0;
no v5.16.0;

package Weird {
use overload '@{}' => sub { [ 1, 2, 3, 4 ] },
'%{}' => sub { { (a=>1, b=>2) } };

sub new {
my $val = "Meaningless.";
bless \$val, 'Weird';
}
}

my $aref = [ 1, 2, 3, 4 ];
my $href = { a => 1, b => 2 };
my $weird = Weird->new;

say "A $_" for keys $aref;
say "H $_" for keys $href;
say "W $_" for keys $weird;

What should the "W" behavior be? In reality, the decision was that to avoid ambiguity, this would be fatal. That means that if you're going to allow things that provide an array ref or hash ref interface, but are not unblessed references, you must add the dereference yourself: "... for keys @$weird" or "... for keys %$weird". So the gain is small. Meanwhile, "push $weird" would work, which sort of shunted keys/values/each into a second class position. Some people were happy with this, sometimes because they thought that arrays should never have picked up keys/values/each.

The problem being solved was, basically, "circumfix dereferencing is a pain." Writing "keys %$foo" is not so bad, but writing "keys $foo->{0}[$x][$z->{index}]" and then realizing you forgot to wrap the expression in @{...} is more onerous. This problem is *also* addressed by postfix dereferencing, and more generically, without ambiguity, and operating in all places instead of a few built-ins.

--
rjbs

On 2021/02/28 09:30, Ricardo Signes wrote:
> On Sun, Feb 28, 2021, at 2:21 AM, L A Walsh wrote:
>> It seems all of the reasons against auto-deref were answered in-so-much
>> that that claims of ambiguity were shown not to exist. For example, in
>> the case of use of 'keys'. Without autoderef, the language requires
>> a perlvar of type ARRAY or HASH with a '@' or a '%' in front of it.
>> Autoderef only supported the option of having a reference to something
>> that would have had an '@' or a '%' in front of it. Since perl always
>> knows the type of vars having an '@' or '%' in front of, then
>> a reference to either can automatically, and unambiguously always be
>> assumed to be of type that would have had an '@' or '%'.
>>
>> So can I ask that it's removal be undone?
>
> The short answer is: this just isn't happening.
>
> I think, but am not sure, that you're a bit confused about the
> realities of the ambiguity of autoderef. Some built-ins can work on
> both hashes and arrays. These include "keys" and "each" and
> "values". (I think that's it.) Also, via overloading, a reference
> may be able to function as both a hash and array reference. Consider
> this program:
>
> use v5.14.0;
> no v5.16.0;
>
> package Weird {
> use overload '@{}' => sub { [ 1, 2, 3, 4 ] },
> '%{}' => sub { { (a=>1, b=>2) } };
>
> sub new {
> my $val = "Meaningless.";
> bless \$val, 'Weird';
> }
> }
>
> my $aref = [ 1, 2, 3, 4 ];
> my $href = { a => 1, b => 2 };
> my $weird = Weird->new;
>
> say "A $_" for keys $aref;
> say "H $_" for keys $href;
> say "W $_" for keys $weird;
>
>
> What should the "W" behavior be?
----
Type of argument to keys on reference must be unblessed hashref or
arrayref at /tmp/rtest line 32.

The behavior should be exactly what is documented. The documentation
says that the refs must be to natural or native @arrays
or %hashes. No other usage is possible. I appreciate your usage of code
to explain the problem, but you are asking the perl language to define case
'W' when it _is_defined_ not to know.

Case A, the language, it knows it is a ref to native type ARRAY.
Case H, the language, the interp knows is a ref to a native type HASH.

Case W, though isn't defined **IN THE LANGUAGE**. Therefore interpreter
CANNOT process it where only an ARRAY (X)OR HASH is required. Note, the
language
only accepts one of 'ARRAY' or 'HASH', not both. It is an XOR operation.

Thus any reference to something that is not, strictly a native ARRAY or
a native HASH must be rejected.

Case W is neither a native ARRAY nor a HASH.

In the above, you can also write this:

Perl defines autoderef to only work when the following
is true for $Xref when the following resolves to an ARRAY or a HASH.

do {
my $t=ref $XREF;
if ($t eq HASH) { %$ref }
elsif ($t eq ARRAY) { @$ref }
else { $ref }
};

If '$Xref' is not reference to a perl-defined type of ARRAY or HASH,
then it is disallowed.


As I've stated before, the only reason detractors have given for
allowing this is that they/you want the deref to work in the
case that _perl_ _doesn't_ _support_. This is a limitation of perl, not
of auto-deref. Perl cannot dereference something that is not already
defined as a type in the language.

A user defined object creates a 'Type' of data that doesn't purely
adhere
to the rules for a native type. Thus perl cannot treat it as one. It makes
no difference that the implementor _wanted_ it to be like an ARRAY or
like a HASH, the implementor has no way of telling perl what they mean other
than by overriding perl's operators and functions to do what they want.

If they want 'Weird' to operate in a specific way, they need to define
that method in their class.
package Wierd;

sub keys($) {
my $w=shift;
if (ref $w ne 'Wierd') { die "Weird::keys only knows about Weird
refs"; }
do { ...whatever Wierd wants }
}

> In reality, the decision was that to avoid ambiguity, this would be
> fatal.
---
In truth, it is only ambiguous because the creator was ambiguous -- not
autoderef. The creator of the class didn't define its behavior in such
a case.


It is a _user_ error to use 'keys' where a method has not been defined.
Perl only defines usage of keys with native ARRAY or HASH's. If a
class-creator
wants to have their class work with keys, they need to define their own key
method.


> That means that if you're going to allow things that provide an array
> ref or hash ref interface, but are not unblessed references, you must
> add the dereference yourself: ...
---
If they want their class to operate with a perl "operator (or
function)"
they need to define the method.


If a user creates a class Complex, and uses 'overload' to provide
methods
for it to work with '+' and '-', how is this any different?

Natively if the creator doesn't define usage for '+' or '-', and they
try to add a value of type 'Complex', it won't work;

To be consistent, you need to disable native '+' and native '-' working
with unblessed integers and floats.

Note, that 'ref $integer' and 'ref $float' return no type. yet
creators of
a class 'Complex' that works with '+' or '-' can only provide
functionality that
works with a reference to their class.

In the case of native ARRAY and HASH, perl, unambiguously returns ARRAY
and HASH -- perl's own data types that it can provide methods for.
All the autoref detractors need to do is provide a method to work when
a ref '$Xref' returns 'Weird' and they are set. End of story.

It is not the case that use of 'autodef' leads to unambiguous behavior,
unless the class designer has not defined the behavior. This is neither a
failing of language nor autoderef, but of the class designer in
neglecting to
define analogous behavior.

How can the language define an operation for an arbitrary class when the
designer of the class has not or _can_ not define that behavior? Detractors
are complaining that perl only defines actions for its own types. So? How
is that a problem? The designers of such types can define actions -- yet
choose not to. How is that a failure defining how native
operator/functions operate on perl-native or ref-to-perl-native types
operate?

On Tue, Mar 2, 2021, at 2:30 PM, L A Walsh wrote:
> As I've stated before, the only reason detractors have given for
> allowing this is that they/you want the deref to work in the
> case that _perl_ _doesn't_ _support_. This is a limitation of perl, not
> of auto-deref. Perl cannot dereference something that is not already
> defined as a type in the language.

In general, in Perl, if something expects to be handed a reference to an array, one can hand in a blessed object that provides array-dereference behavior. autoderef broke that.

Your argument sounds, to me, like "Yes, but it said it was going to break that, so it's fine."

On the other hand, it makes autoderef less appealing, because "use a virtual array reference" becomes less safe.

At any rate, this debate happened years ago. I considered the matter settled then, and I still do now, and I don't really plan to entertain further discussion on this feature. The ship has sailed, and I'm glad to see it vanished over the horizon.

--
rjbs

On 2021/03/02 12:24, Ricardo Signes wrote:
> On Tue, Mar 2, 2021, at 2:30 PM, L A Walsh wrote:
>> As I've stated before, the only reason detractors have given for
>> allowing this is that they/you want the deref to work in the
>> case that _perl_ _doesn't_ _support_. This is a limitation of perl, not
>> of auto-deref. Perl cannot dereference something that is not already
>> defined as a type in the language.
>
> In general, in Perl, if something expects to be handed a reference to
> an array, one can hand in a blessed object that provides
> array-dereference behavior. autoderef broke that.
---
Looking at perlref, Perl doesn't have any functions where it expects
to be handed an array ref. This is a place where it expects to be handed
an ARRAY. Autoderef also allows it to be handed a reference in the same
places it accepts a real ARRAY. A reference to another data type can't
use those functions unless it provides a METHOD to convert from the other
data type to an ARRAY.
>
> Your argument sounds, to me, like "Yes, but it said it was going to
> break that, so it's fine."
>
> On the other hand, it makes autoderef less appealing, because "use a
> virtual array reference" becomes less safe.
----
Perl never has supported a virtual array ref as identical to an array.
If someone uses it that way, it's trying to apply perl's array semantics
on non-array objects. If those objects don't define the same operations,
that is there choice. It doesn't break any code, because no code using
a non-ARRAY object reference could be used in those locations.

It can only break new, unwritten code. What you are claiming is
that perl can never be expanded in ways it was never used, because the
new ways don't support all the user-types supported by perl for builtin
objects.

They *can*, if they provide a method. But that's future facing -- not
past facing. I wrote an ARRAY based class that provided the methods
for references to the class that worked with perl's builtins. It's
quite possible for others to do the same with their classes if they want
those classes to act like ARRAYS's.
>
> At any rate, this debate happened years ago. I considered the matter
> settled then, and I still do now, and I don't really plan to entertain
> further discussion on this feature. The ship has sailed, and I'm glad
> to see it vanished over the horizon.
---
That's an argument listed under "logical fallacies". "It's this way
now, so it will always be this way, thus we we have decided so help me, me."

A pronouncement of a past judgment that is no longer true simply
means new information makes the old judgment false. You aren't the Pope
who claims that because the church believed to be the earth flat
believes it still to be true? New information comes along and still
upsets reality today.

When I was a child, it was taught that the shape of
a wing was what gave airplanes their life. Now that is known to be false.
Indeed *most* of the thrust against gravity comes from the wing angling
down and providing a direct downward force to negate gravity. But until
the 80's or 90's, people still believed the "truth" that had been so since
the earliest days of flight.

You have knew knowledge -- that pseudo-array classes can provide their
own methods if they wish to retain compatibility with perl-refs that
work with ARRAY methods. This isn't a change that causes old code to
break. It is a change that only applies to future code that wishes to
have user-refs be compatible with perl's builtin ARRAY and HASH datatypes.

Standing against anything that allows perl to evolve that doesn't break
old code is making perl a dead language. The only languages that don't
evolve are dead languages -- ask speakers of Latin...except there are no
native speakers of Latin. They are all gone. Thus Latin is considered
by linguists to be a dead language.

If you insist that perl not evolve -- you are consigning it to death
*by definition* ? -QED

On Tue, Mar 2, 2021, at 5:52 PM, L A Walsh wrote:
> If you insist that perl not evolve -- you are consigning it to death
> *by definition* ? -QED

You're not talking about evolution, you're talking about bringing back the dinosaurs, which have already sprung into existence, had their lives, and died. I have already seen Jurassic Park, and I know how that ends.

autoderef is not coming back.

--
rjbs

On 2021/03/02 12:24, Ricardo Signes wrote:
> On Tue, Mar 2, 2021, at 2:30 PM, L A Walsh wrote:
>> As I've stated before, the only reason detractors have given for
>> allowing this is that they/you want the deref to work in the
>> case that _perl_ _doesn't_ _support_. This is a limitation of perl, not
>> of auto-deref. Perl cannot dereference something that is not already
>> defined as a type in the language.
>
> In general, in Perl, if something expects to be handed a reference to
> an array, one can hand in a blessed object that provides
> array-dereference behavior.
----
"In general"? Please state where in the documentation for perl that
this
is a documented feature. There's no guarantee that such is a feature
in perl. More to the point,
> autoderef broke that.
>
> Your argument sounds, to me, like "Yes, but it said it was going to
> break that, so it's fine."
----
There is nothing to break. Your statement is complete fabrication based
on what some people may have been assuming but goes against object oriented
design. You are violating basic rules regarding OO languages.

In the same way you claim a random blessed object provides
array dereference behavior, the same random object could be claimed to have
hash dereference behavior. You are claiming an object can claim to be
both '0' and '1' at the same time which is clearly not a feature of a
deterministic computer language.

When someone made that statement before, I asked, "How does Perl know
an object provides array-dereference behavior. How can perl know if it
provides array-dereference behavior or hash-dereference behavior. Such
a statement is meaningless since there is nothing in the language to
specify such a behavior.

You are personally guaranteeing perl will honor something that has
no mechanism in the language to be specified. The only way something can
provide such behavior is to provide all the methods that apply to an
Array and duplicate the behavior of perl's arrays. If they did that,
there would be no issue with perl autodereferencing such objects, as
those methods would have been duplicated in those objects.

What you are claiming is because some group of your buddies want
their assumptions to be true, you are willing to neuter perl because they
don't want to provide methods for their classes to actually duplicate
array behavior.

If you continue on this path you are only proving that perl is a
personal playground of those allowed to contribute to it. Since perl-5.18,
perl has gone from being in the top 10 languages, past the point of
being dead last and most hated to work or develop in, to falling off
the charts. Latest charts on languages being used or liked by developers
no longer included perl.

The current development group has abandoned most users to the point
that I've wondered if some in leadership positions really have the
goal of killing off perl or if it just part of the larger problem
working to reduce pc ownership and computer knowledge.

to kill perl Perl servers are being
shut down because they have too few users and perl is being retired
because it doesn't listen to its user base and only listens to an
increasing shrinking developer base that is losing the resources to
maintain the codebase, let alone have it grown.

At least two years ago, I was told that there was no one on the
perl development team that knew how the language parser worked and
no one wanted to make changes in it for fear of breaking it. I wasn't
sure whether it was true or not, but

From the keyboard of Ricardo Signes [02.03.21,19:19]:

> On Tue, Mar 2, 2021, at 5:52 PM, L A Walsh wrote:
>     If you insist that perl not evolve -- you are consigning it to death
> *by definition* ? -QED
>
>
> You're not talking about evolution, you're talking about bringing back the dinosaurs, which
> have already sprung into existence, had their lives, and died.  I have already seen
> Jurassic Park, and I know how that ends.

Can we please abstain from blowing up a mouse to the size of an elefant?
We are talking about syntactic sugar here, not about dinosaurs - "multi
dimensional array emulation" (think $;) is a dinosaur in that scheme,
while autoderef is not.

But sugar can be poisonous. Some say it is always poisonous if not found
in an aggregate.

As a long-time perl user (my first perl was v4 patchlevel 16) these are
my few cents...

> autoderef is not coming back.

I don't object, and here is why - plus some other remarks:

1. I want to be clear in what I'm talking about. $foo is a SCALAR, %foo
is a HASH, @foo an ARRAY. If $foo contains a reference to a HASH, I
talk about it as %$foo, if ARRAY, then @$foo. The 'autoderef' thingy
blurs that and "goes PHP", where any variable is prefixed with "$".

2. I have never used auto-deref, and where I (accidentally) did, it did
not help. Trading a keystroke for clarity is a bad deal.

3. All that talk about native type vs. blessed native type aka objects
goes right back to the (permissive) implementation of objects in perl
where a blessed hash reference can be used as, well, a hash reference
and as an object which calles methods. Which was arguably a bad idea,
but that ship has sailed long ago.

4. I never used postfix-deref - $foo->@* and such - which in my eyes is
an abomination turning the sigil system upside down. It is another
hurdle for those having to wrap around their head at @{$h->{$a->[$i]}}

5. Making "keys", "values" and "each" work on arrays is a spectacular
braindead decision. When has this been called for? based on what
rationale? In my book, "keys" refers to the keys of an associative
array, "values" to the values only, and "each" to tuples comprised
of both of them. Nothing to do with arrays, whose entries are
accessed via indices, and if flattened give a list.

6. All those snarky remarks about merits of perl core developer folks
I read in the links shown in this thread are uncalled for and make
me very sad. They are in no way perlish.

7. That said, if someone wants rope to hang themselves, give 'em.
'autoderef' could be a feature as is 'arraybase' (wait, is that in
place anymore?) if not too much work - and if it is, that should be
cared of by those who want the "feature".

I know that these remarks are uncalled for, but I needed to vent a bit
and provide a view of "someone out there" with no stakes in the perl
core development. Sorry for wasting your time, and thanks for the
attention so far.

best regards - and keep up the good work,
0--gg-

> -- 
> rjbs
>
>

--
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

On Wed, Mar 3, 2021, at 5:00 AM, L A Walsh wrote:
> > In general, in Perl, if something expects to be handed a reference to
> > an array, one can hand in a blessed object that provides
> > array-dereference behavior.
> ----
> "In general"? Please state where in the documentation for perl that
> this
> is a documented feature.

perldoc "overload" under "Dereferencing."

> When someone made that statement before, I asked, "How does Perl know
> an object provides array-dereference behavior. How can perl know if it
> provides array-dereference behavior or hash-dereference behavior. Such
> a statement is meaningless since there is nothing in the language to
> specify such a behavior.

"overload" is a well defined mechanism. This has been present since at least 5.005.

I do not plan to engage more on this. The matter was settled long ago and we (steering) are of one mind on the question of autoderef.

--
rjbs

On 3/3/21 9:14 AM, shmem wrote:
>
>
> 5. Making "keys", "values" and "each" work on arrays is a spectacular
>    braindead decision. When has this been called for? based on what
>    rationale? In my book, "keys" refers to the keys of an associative
>    array, "values" to the values only, and "each" to tuples comprised
>    of both of them. Nothing to do with arrays, whose entries are
>    accessed via indices, and if flattened give a list.

making those 'work' on scalars that are auto-derefed was braindead.
making them work on real arrays is actually pretty useful. i have had
need to get the indices and values of an array (there are many useful
needs for those indices) and each does that. otherwise you need to do
you own indexing and accessing the value in the array

foreach (my $i = 0 ; $i++ ; $i < $#array ) {
    my $val = $array[$i] ;

while( my( $i, $val ) = each @array ) {

and it is also cleaner with an array ref.

and no need to know to use $#array vs @array.

keys and values are of pretty low need for arrays. they added them for
consistancy when auto-deref was done.

uri

On 2021/02/28 00:18, Veesh Goldman wrote:
> I don't see how you came to this conclusion.
>
> Very simply, you are requesting a misfeatures. If you are writing a
> sub, now you have to be defensive and check that the array-like thing
> that was passed in isn't an object. You literally only gain bugs by
> subtly disallowing Mojo::Collection objects to be passed in even
> though they are INTENDED to be used as an array.
>
> Your arguments about objects being opaque is also misled. Objects ARE
> opaque, and therefore if they tell you that they can be used as an
> array, it shouldn't matter if its blessed or not.
---
This is where the breakage occurs. How are "they" telling a user
like me _anything_. Users don't hear the voices of objects.

I asked, how are the objects telling *perl* what they are.
I even suggested they could claim they "ISA" an ARRAY,
I did that with a HASH based class and 'keys' was able to
tell that what it was. It works, it's simple. and it works
by telling PERL what it is. But a class can't tell 'users'
anything because users aren't executing the programs in their
heads.

The whole reason for disallowing perl to deref its native types
was because class writers refused to come up with a way to participate
in the benefit, and in a classic sour grapes ploy claimed that
perl's native data types shouldn't be able to benefit either.

If that's the case, then all of the functions that currently
work with ARRAY's and HASHES (push/pop/keys, etc) should be
removed because they give special treatment to native data
structures. But that wouldn't be compatible -- and that
really is the point -- perl has NEVER supported object's using
those functions. When it was proposed that ref's to perl's
own data types be allowed in those functions, it's not _breaking_
any existing functionality -- because those functions have NEVER
worked on objects -- nor have they worked on reference to those
objects unless the coders have put '@' or '%' on the objects.
Disallowing perl to dereference its native data structures
is hamstring perl for the sake of alien data structures that
are not builtin.

If they want to participate, they should have come up with a
method to do so rather than disallowing perl an easier way
to reference its own native data structures. Regardless,
I did come up with a way for objects that want to declare
themselves, to perl (not to users!), that they want to be
treated as arrays or hashes, to also be autoderef'ed.

The method you claim isn't there for objects is. The choice to
use it or not is on those providing the objects. Perl can't
do their work for them. It knows how to auto-deref it's own
data types, and that's it. To prevent that is extreme laziness
and self-centered-ness. It's the unwillingness to make use
of a technically correct solution because ...? No comment.

There is no valid technical reason to disallow the undoing of
auto-deref.

On Fri, Jun 11, 2021, 06:57 L A Walsh <astara@tlinx.org> wrote:

> On 2021/02/28 00:18, Veesh Goldman wrote:
>
> > Your arguments about objects being opaque is also misled. Objects ARE
> > opaque, and therefore if they tell you that they can be used as an
> > array, it shouldn't matter if its blessed or not.
> ---
> This is where the breakage occurs. How are "they" telling a user
> like me _anything_. Users don't hear the voices of objects.

It's called documentation. This while discussion is about surprising USERS,
not perl. Code is for humans, not computers. If you wanted something that
only computers understand, you should write binary.

>
> There is no valid technical reason to disallow the undoing of
> auto-deref.
>
I fail to see how you reached this conclusion.