I'm unable to follow the whole thread in depth, but the point I'd like to make
is directly related to the initial example. My question would be: what exactly
do we undefine? I mean, all the discussion about definedness and truthiness is
undoubtedly great, and I mean no pun here. Special thanks Ralph for clarifying
some stuff which I never spoke out explicitly to myself. Yet, the matter of
containerization seems to be left aside to no purpose.
First of all, what would [1,@a].map(-> \v { v.VAR.^name }) produce? Double
Scalar.
Second, what sense `1.&undefined` makes? None. For sure, it fails.
1 and 2 together, what happens when we `[1, @a].map: *.&undefine`? We use the
scalar int the 0th array element, then we use... Array? But @a is scalarised
too, according to .VAR result! As a matter of fact, what we have is:
my $a0 = 1; my $a1 = @a; ($a0, $a1).map: *.&undefine;
In a consistent case one with knowledge of containers would rather expect it to
be `$a0 = Nil; $a1 = Nil;` Therefore, the original array of `[1, @a]` should
end up being `[$(Any), $(Any)]`.
One can say that Scalar container transparency is very much a matter of
convention. In this case what sense does `undefine` makes on an Array? As a
container, it cannot be undefined as such. And how term 'undefine' turns into
'emptify' remains kind of mystery. :)
Another aspect of conventions about transparency is that why are we transparent
depending on the containerized value? For example, `for` doesn't care, it
either sees an item, or it sees an iterable – period. And, suddenly, there is
an exception! Because, otherwise, my initial example should've thrown on `1`
the same way, as in `1.&undefine`. But it doesn't and this break the principle
of equality in the face of law.
One way or another, I don't an alternative to the deprecation. I also agree to
the question (I think it was Ralph who expressed it) of what do we expect from
the routine? Falsification, undefining, or ...? Say, we introduce method
`reset`. It would drop all containers to their defaults. But what about
non-containerized values? What about containerization of array elements? Say,
for the non-containers the method may do nothing as this is their default
value. But array elements?
The case would be more clear if we replace array with a list: `(1, @a, $b)` In
this case the containerization is preserved and the behavior is unambiguous. It
also points at the array case and makes the situation more towards element
container having priority over it's value. After all, we always can `@a[1] :=
[1,2]` and end up with array being the item's container.
But at this point let's sit back for a moment and think of this: you see a
problem in my reasoning about how hypothetical `reset` method could act then it
means others may lean either towards my view, or yours and this segregation of
views makes method's existence rather problematic. Unless some kind of voting
would display overwhelming majority of one party. ;)
Just to conclude, I'm not trying to prove something. Just sharing thoughts.
Best regards,
Vadim Belman
> On Mar 13, 2023, at 11:42 PM, rir <rir...@comcast.net> wrote:
>
>
> undefine seen at:
> <unknown file>, line 1
> Will be removed with release v6.e!
> Please use another way: assign a Nil; for Arrays/Hashes, assign Empty or
> () instead.
>
> Will that deprecation require a conditional and two assignments
> for mixed data?
>
> [$a, @a, $b, %c, $c, &d].map: { .&undefine};
>
> [$a, @a, $b, %c, $c, &d].map(
> { $_ = $_ ~~ (Associative,Positional).any ?? Empty !! Nil });
>
