develooper Front page | perl.perl6.users | Postings from March 2023

Re: Undefine mixed data

Thread Previous | Thread Next
March 17, 2023 23:11
Re: Undefine mixed data
Message ID:
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.


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:
> > On 2023. 03. 14. 4:42, rir 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 });
> > 
> > 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"...

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About