Undefine mixed data

[rir]

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 });

[rir]

Marton: apologies for badly characterizing your post. I particularly
wanted specify the breakage you mentioned for any beginners passing by;
got delayed and forgot about some of your post.

I just mentioned the basic dual nature of Nil. There is a lot of
complexity around 'Nil' and around containerization, without using
them together.

Restating my initial point: Deprecating 'undefine' is just making
something easy more difficult. Not finding any justification for this
change, I now see it as self-inflicted bug scheduled to arrive soon.

I have had some thoughts similar to yours about how containers might be
implemented, but I think education about the current state is a good path.
That could be more docs, and also callables which may have little point
but as educational demonstrations.

Rob

On Fri, Mar 17, 2023 at 04:58:30PM -0400, rir wrote:
> Marton, I am not sure of your meaning. I took the warning message as:
>
> For Scalars assign a Nil, for Arrays/Hashes/Etc. use Empty or ().
>
> Because you might be read as suggesting "@ary = Nil should undefine @ary";
> I will point out that will conflict with:
>
> @a = Nil;
>
> which is defined to assign the RHS entry to the first element of @a.
> I suspect there is no way to destroy a container but to smash it into
> a scope wall.
>
> Some day I shall get serious about understanding Raku's containers.
> In the meantime, I'll just keep creeping up on them and observing.
>
> Rob
>
>
> On Tue, Mar 14, 2023 at 01:38:22PM +0100, Polgár Márton wrote:

> > And even those ways don't seem too convincing... after all, it's more a
> > question of containerization if assigning Nil will cut it or not. I didn't
> > know about undefine but it appeared to me as an issue that you can just
> > assign Nil to an Array and get something that is not the default value -
> > moreover, it doesn't even evaluate to boolean False!
> >
> > It seemed like something that can wait and that could cause a lot of
> > friction as a breaking change but I think it would make overwhelmingly more
> > sense to make Nil always set the default. It is a special value of a special
> > singularity type on its own; it's questionable whether it should ever appear
> > as an assigned element of a composite container but to make it STORE in a
> > special, resetting way, seems kind of a no-brainer, apart from the
> > "breakage"...
>

[Vadim Belman]

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