Front page | perl.perl6.users |
Postings from March 2023
Re: Undefine mixed data
Thread Previous
|
Thread Next
From:
rir
Date:
March 20, 2023 18:56
Subject:
Re: Undefine mixed data
Message ID:
20230320185622.tiv6dt2uzifyghfv@shrew
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<rirans@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
Thread Previous
|
Thread Next