Re: Concerning the branch smoke-me/arc/deprecate-delete-array

* Father Chrysostomos <spr...@cpan.org> [2014-08-21 05:40]:
> I don't know why you find it confusing. I have been programming in> JavaScript for eighteen years and have never found the feature> confusing there. I was delighted when I found that Perl has the same> feature.

I don’t find it confusing any more because I know what the behaviour is,
but there is no way to learn what it is than by just running all your
expectations to the contrary aground, which is why I call it confusing.

Arrays in Javascript do not have this problem. Semantically they are
just hashes with one magic property, and if you approach them as such
you get exactly the behaviour you would expect. (Most arrays will not
actually be implemented that way, but that implementation does not leak
out to the Javascript level in the slightest.) Even so, the feature
feels weird to me – but, it never confused me, because it is clear what
to expect and all behaviour conforms to that expectation.

In contrast, arrays in Perl were designed as entirely different beasts
from hashes. You can’t cleanly convert them to hash semantics. Even now,
Perl does not have actual sparse arrays, only array slots that may
contain no-value-at-all, which is directly exposed to the user e.g. by
the value of scalar(@array). But in a hash, deleting one key deletes one
key. In an array, deleting the last element may shorten it by a thousand
elements. This is handled differently from Javascript:

    $ perl -E '$,=" "; my @x; $x[9] = 1; say 0+@x, 0+keys@x; delete $x[9]; say 0+@x, 0+keys @x'
    10 10
    0 0

    > (function(){ var x = []; x[9] = 1; console.log(x.length,Object.keys(x).length); delete x[9]; console.log(x.length,Object.keys(x).length) })()
    10 1
    10 0

Arrays in Javascript are completely self-consistent in their semantics.
In Perl, they have this bundle of sorta-contradictory behaviours now,
where they partly behave like sparse arrays and partly not, and you can
really only figure out when they do and when they don’t by memorising
all the cases.

And you cannot just say fine, then we’ll make Perl arrays work just like
Javascript arrays – certainly not now, but not even back when this dash
of sparseness was added. Because they were not designed that way in the
first place, and therefore existing code and expectations ran against
that. That was the problem with keys(@array): people already used to
Perl arrays expected it to simply return 0..$#array. In one sense it
would have been more correct to make it leave out non-existent elements,
but then that would have surprised other people. And then of course
each(@array) cannot do something entirely different. Etc.

It’s basically the Perl 6 lesson: you may want to tug at just one corner
but you invariably tug at the whole thing. Some decisions you make at
the start cannot then be undone locally.

> BTW, I agree that 'each @array' was not well-conceived. No so for> sparse arrays.

It *couldn’t* have been. Either way it was defined would have been the
wrong choice for some set of users.

> It is already hookable via PL_check. But if perl's internal array> functions stop supporting this, then I would have to tie every array> affected or hook all array operations to keep things in synch. It> seems like more bother than it is worth. (Not upgrading seems rather> attractive by comparison.)

Hrm. Yeah.

What if non-value slots were still supported in AVs but visibility at
the Perl level were shunted off to some Scalar::Util function? (Or to
a function in a newly added Array::Util if you prefer. It’s just that
List::Util feels like the wrong place.)

I *think* the difference between empty vs undef array slots is already
invisible unless you go looking, so this would just amount to removing
the syntax and making this a pure, space-saving implementation detail,
except something similar to your arybase pragma could support existing
users indefinitely.

Would that be acceptable to you?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>