Marton, I like the practicality of your advice to preferring scalar containers.
Do you think 'undefine' should go away in 6.e with only the proposed replacements? Marton wrote: > 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 Here I have lost the antecedent to 'that'. I don't know to what "a scheduled fix" refers. Rob On Sat, Mar 18, 2023 at 07:30:59PM +0100, Polgár Márton wrote: > 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
