For what it's worth, I think most of these behaviors that sometimes even
contradict each other (like the "freshly undefined" array being both
.defined and .DEFINITE) are just design mistakes from a different time.
It was never "the right thing" that you cannot reasonably indicate for
an array that it doesn't have valid content, as opposed to being empty
by chance - this is a reason to /avoid /@variables, if anything.
Similarly, it does no good, ever, that you get to store a Nil value (is
it even a "value" from high-level perspective? Perhaps not) in an array
on an assignment, and afterwards the array won't even be empty and lives
on as something that genuinely holds data.
What differs, though, is the cost of changes. To introduce the concept
of definedness/definiteness for @variables now, that would both be a
serious challenge from implementation point of view, and a severely
breaking change; no matter how we feel about it (I think it /would be
/the right thing). On the other hand, assignment of Nil is barely
defensible exactly because of its uselessness. I'm willing to bet my
life that nobody ever seriously used `@foo = Nil` to mean "yeah, I want
a one-element array with exactly one Nil value in it". Also, since the
already highly distinguished nature of Nil, I'm absolutely certain that
it wouldn't take a lot to make `@foo = Nil` reset the array (or whatever
Positional container we provide in addition; can't think of anything else).
I realize that 6.e is kind of a packed project so I wouldn't insist on
quickly messing things up to test this out but since we were talking
about a "scheduled bug" anyway, I think that could be a "scheduled fix".
Of course this is all just my opinion and this feels like something
reasonably simple to achieve; simple enough that I can take up on it
when the time comes. Objections are welcome, except the kind that refers
to the breaking nature and legacy reasons.
On 2023. 03. 18. 19:06, Ralph Mellor wrote:
On Fri, Mar 17, 2023 at 11:11 PM rir<rir...@comcast.net> wrote:
Deprecating 'undefine' is just making something easy more difficult.
I see a problem with `undefine`:
```
my @bar;
say @bar.defined, @bar.DEFINITE; # TrueTrue
undefine @bar;
say @bar.defined, @bar.DEFINITE; # TrueTrue
```
I think a warning about this is the wrong solution.
I think deprecation is the right solution.
----
That said, I'm a bit surprised that the deprecation message isn't something like
Please use `foobar` instead
(where `foobar` does exactly the same thing as `undefine`, just using
a different name).
----
Maybe no one has yet thought of a name that isn't also fraught?
Maybe there is no reasonable name?
Maybe it's only Perl folk who would want `undefine`?
Maybe it's only Perl folk who will see the deprecation message and be unhappy?
Maybe, on balance, it's reasonable to consider it an opportunity to remind Perl
folk that a fresh uninitialized array or hash is NOT undefined?
Dunno. Just keeping an open mind.
Onward...
----
I searched Rakudo's sources for "undefine".
No useful match?!? Looks like GH search goes from bad to worse. Sigh.
----
`say &undefine.file` got me `SETTING::src/core.d/operators.pm6`:
https://github.com/rakudo/rakudo/blob/591157170d29f8a45ef316bb0d065e8437059112/src/core.d/operators.pm6#L1-L9:
Git blame led to this commit:
https://github.com/rakudo/rakudo/commit/72bac6708002f992952ca93e617435482824b95f
The commit message mentions "6.d-prep".
A google for that led to:
https://github.com/Raku/6.d-prep
Results of a GH search included
https://github.com/Raku/6.d-prep/search?q=undefine&type=issues
I ask that no one here comments on the discussions therein unless
they are *very* careful to avoid using inflammatory language.
----
Next I decided to search IRC. That led to this by Larry:
I think we should s/undefine/clear/, because clarity
(https://irclogs.raku.org/perl6/2015-07-02.html#17:19-0001
----
Liz suggested it was perhaps redundant.
(A similar argument appeared in the 6d prep issues.)
Larry didn't reply. Warnock's dilemma applies though I don't think
Larry ever missed anything. I think he always went with his gut; if
he felt he'd be repeating himself he said nothing.
----
And so we arrive at 2023 and the same issue arises as ever.
Can we be kind to each other even if we don't agree, even if we
are upset about some decision?
----
love, ralph
