On Mon, Mar 20, 2023 at 10:42:45PM +, Ralph Mellor wrote:
> On Mon, Mar 20, 2023 at 12:49 AM rir wrote:
> >
> > I did, and do, recognize the validity of the problem of 'undefine' not
> > not aligning with '.defined'.
>
> But do you understand the problem I was trying to communicate?
Possibly
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
If you made actual evidential arguments why it's good that Nil gets fed
into @variables on assignment, or why is it good that @variables are,
yes, both defined and DEFINITE when only declared, why this
inconsistency, or counterpointing design,with $variables, is a good
thing, we could discuss t
I see weaknesses in my attempt to explain Raku's design related to
"definedness".
(I personally think there would best be a documentation page dedicated to the
triumvirate of definiteness, definedness, and truthiness, but here I'm trying to
achieve a balance between being short enough for this con
Grr, sorry for the spam. After all this trying, the last part still
couldn't be delivered. So here is the whole message instead:
https://gist.github.com/2colours/53b3c3108b0a44fa559eeed0370c26bf.
it does no good, ever, that you get to store a Nil value ... in an array
Why do you think the `is default(Nil)` idiom for storing `Nil`s in `Scalar`s
is OK except when the `Scalar`s are inside an array?
I grant that, as jnthn put it in an SO discussing this:
While there is the `is default(Ni
(Since this mail couldn't be delivered at first, I'll try to
aggressively split it this time...)
Dear Ralph,
I'm sorry that you get frustrated but this is still for all intents and
purposes a technical discussion so I don't think it does any good to be
vocal about it. There are good points an
On Sat, Mar 18, 2023 at 6:28 PM 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.
There are no mistakes
On Mon, Mar 20, 2023 at 10:42 PM Ralph Mellor wrote:
>
> * Definiteness or definedness? If you want it indefinite (or undefined),
> call `.WHAT` on the argument.
That should be "Bind the result of `.WHAT` called on the argument".
Similarly:
> * Truthiness? Want a fresh false instance? Call `.ne
On Mon, Mar 20, 2023 at 12:49 AM rir wrote:
>
> I did, and do, recognize the validity of the problem of 'undefine' not
> not aligning with '.defined'.
But do you understand the problem I was trying to communicate?
What you're writing suggests to me you know some other PL(s) that
have notions of
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 co
Ralph, we agree on my primary complaint that utility/convenience is being
lost.
I did, and do, recognize the validity of the problem of 'undefine' not
not aligning with '.defined'. The docs indicate that being empty is the
definition of undefinedness for non-scalar containers.
Keeping 'undefine
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 t
On Fri, Mar 17, 2023 at 11:11 PM rir 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 t
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 contain
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 ass
On 2023. 03. 14. 4:42, rir wrote:
undefine seen at:
, 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
Hi,
I don't know if I understood your question correctly; I tried two
alternative ways to assign Nil using the REPL:
[0] > my ($a, @b, %c, &d)
((Any) [] {} (Callable))
[1] > [$a, @b, %c, &d] »=» Nil
[(Any) [] {} (Any)]
[2] > say "{$a.^name} {@b.^name} {%c.^name} {&d.^name}"
Any Array Hash Callabl
undefine seen at:
, 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
19 matches
Mail list logo
