There is a thematic page on Github for a while called Discussions. In
the case of the Raku/problem-solving repository, it's second next to
Issues, and next to Pull requests. The direct link to this particular
discussion is https://github.com/Raku/problem-solving/discussions/395.
On 2023. 10.
eclared name:
_ used at line 1
[5] > dd :_:
No such method 'dd' for invocant of type 'Pair'
in block at line 1
On Sep 24, 2023, at 23:40, Polgár Márton
wrote:
Hi Bill,
:_ is a Pair with the colon syntax that stands for "_" => True. In
the first case, it got passed
Hi Bill,
:_ is a Pair with the colon syntax that stands for "_" => True. In the first
case, it got passed as a named argument and say ignored it. The second case was
a method call using the colon syntax - the syntax lizmat challenged not so long
ago.
Hi,
for those of you not paying close attention to Reddit or the Telegram
group of the Raku Conference - Andrew Shitov has already proposed a date
for the conference this year:
https://www.reddit.com/r/rakulang/comments/15y82fq/the_raku_conference_2023_date/
Feel free to share your thoughts
Hi,
since the broader topic of Raku documentation came up on a SF Raku Study
Group meeting - and there have been various important news since - it
seems fitting to announce the planned schedule for the next couple of
documentation meetups, as it became publicly available at
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,
(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
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
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.
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
I think this is the classic case of ?-twigilled, "compile-time"
variables only being available in modules. It kind of forces you to
always have the pattern of: heavy-lifting in a module inside lib, and
the script just uses the module.
On 2023. 04. 17. 18:01, David Santiago wrote:
I'm trying
On Mon, Apr 17, 2023, 11:48 AM David Santiago
wrote:
Hi Polgár
A seg, 17-04-2023 às 18:08 +0200, Polgár Márton escreveu:
> I think this is the classic case of ?-twigilled, "compile-time"
> variables only being available in module
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
Hey, you thought right! We were just doing a little testing (or at least
offered to do) so that functionality concerns can be checked.
By the way, I brought up the example of the Rakudo classes were Jitsi
kind of failed us and the second occasion was moved to Zoom. It could be
that something
14 matches
Mail list logo
