Front page | perl.perl6.users |
Postings from March 2023
Re: Undefine mixed data
Thread Previous
|
Thread Next
From:
Vadim Belman
Date:
March 22, 2023 01:25
Subject:
Re: Undefine mixed data
Message ID:
5EAC7B22-1D7F-4A26-8D90-C72B24932357@lflat.org
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 <rirans@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 });
>
Thread Previous
|
Thread Next