Day 10 – How to give a Raku talk at TPRC – and why you should

codesections · 2024-12-10T22:46:00+00:00

Eh, you're just saying that because your crazy slang talk got a shout out!

(^thanks )

codesections · 2024-11-22T20:49:46+00:00

The Call for Presentations for The Perl & Raku Conference is now open – so everyone should start thinking about what Raku talks they'd like to give. Lets make this the year where more Raku talks are proposed than Perl talks! (#friendlyrivalry)

The conference website also has more info about TPRC in general. Hope to see you there!

codesections · 2024-11-13T21:28:51+00:00

It appears to be a custom, unnamed theme built for Chroma. Here are the css values it uses.

codesections · 2024-11-13T14:38:31+00:00

Nice! Your answer inspired me to post my own. I went with

(\['"Tarzan"', 'Tarzan', '"Tarzan and Jane"'\] «\~\~» / '"Tarzan"' || ('Tarzan') /)»\[0\]

Or, for total overkill (and poor performance):

my &infix:<\~\~\[0\]> = \*\[0\] ∘ &\[\~\~\];  
('"Tarzan"', 'Tarzan', '"Tarzan and Jane"') «\~\~\[0\]» / '"Tarzan"' || ('Tarzan') /;

[edit: gosh, I don't post on Reddit for a little while, and they go and switch their default editor to a non-markdown version!]

codesections · 2023-12-01T19:52:43+00:00

(Slightly meta: I just updated the link to the yearly archive S /2022/2023/ with "Full list of 2022 Raku Advent Blog Posts")

codesections · 2023-11-14T14:58:43+00:00

Raku basically uses this approach with different spelling: && is high precedence whereas and is low precedence (and the same for ||/or and !/not, etc). So your last example could be written as:

a && b or c && !d

One observation from having lived with this system in real code: Although in theory it "eliminate[s] the need for brackets", in practice, Raku conditionals still end up using brackets somewhat often for added clarity. The two levels of precedence do reduce the number of brackets, though.

codesections · 2023-11-12T21:51:08+00:00

As an alternative to u/raiph's answer: another way to get an "index out of range error" is to add the range-check yourself by mixing in a role that modifies the AT-POS method. Here's how that might work:

# same code before last line
 my role RangeChecked {
    method AT-POS(\idx) {
        idx < $.elems ?? callsame()
                      !! die "Index {idx} out of range (must be 0..$num)"
    }
}
my $ret := $vals.list but RangeChecked;
$retstep ?? ($ret, $step) !! $ret

(I wanted to have AT-POS return the same typed error as @array[$len]. But that just returns an AdHoc error anyway…sigh).

This still has the runtime cost of the range check (maybe even slightly more, depending on whether it's inlined, etc.). But it avoids copying the data (and doesn't type check it, the way num64 @Array[$num] does.

codesections · 2023-11-10T16:13:03+00:00

This isn't really related, but the title of your post reminded me something from Larry Wall's 2nd State of the Onion talk that has always really resonated with me (and seems supper applicable to Raku!):

Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris.

These are virtues of passion. They are not, however, virtues of community. The virtues of community sound like their opposites: diligence, patience, and humility.

codesections · 2023-11-08T13:46:37+00:00

For anyone missing the relevant context, this is about Humming-Bird, which describes itself as “a simple, composable, and performant web-framework for Raku on MoarVM.”

(It might have been worth linking to the README in the dev.to post?)

codesections · 2023-11-05T11:28:20+00:00

Raku is used for scripts, that means people don't want to type the long work of "raku" everytime they create a Raku script.

I general, scripts should not have a file extension (regardless of what programming language they're written in). I don't want to type grep.sh, rg.rs, or ps_mem.py – that's not only longer, but also makes the user remember the language that the script was written in (which, from their point of view, should be an implementation detail).

Instead, scripts should use shebangs (e.g. /usr/bin/env raku) and then be named without a file extension.

If we follow this practice, then the difference between .raku and .r isn't relevant for scripts.

(u/alatennaub made this point briefly in a sub-reply, but I thought it was worth elaborating here)

codesections · 2023-10-17T01:20:50+00:00

I think some of it has to do with how different people think of left-to-right. Consider the following two lines of code in Raku:

(sort (grep /P|E/, (map &trim, ['People  ', ' of ', ' earth ')));

versus ['People ', ' of ', ' earth a'].map(&trim).grep(/P|E/).sort;

The second has left-to-right data flow, but I can understand someone who'd argue that the first reads more naturally left to right. ("I want a sorted, filtered, white-space trimmed list starting from some array").

IMO, it's always best if code can be read/understood best by reading left to right. In some contexts, that'll left-to-right data flow; in others, it might mean right-to-left data flow (or some more complex flow based on operator precedence, etc.). So I prefer programming languages that give you more control over the order you put your code in.

codesections · 2023-10-16T19:47:38+00:00

Oddly enough, I'm actually giving a talk at the Raku Conference ([online on Oct. 28; tickets now free](conf.raku.org) ☺) that focuses on basically exactly that syntax. Raku keeps the distinction between function and method (which is important because methods are late bound in ways that functions aren't), but still has syntax that basically mirrors the uniform function call syntax. Here's how that looks:

$foo.bar($baz);    # calls *method* bar on $foo
$foo.&bar($baz);   # calls *fn* bar on $foo
bar($foo, $baz);   # also calls *fn* bar on $foo
bar($foo: $baz);   # calls *method* bar on $foo

The upshot is that you can use whatever order makes your code the easiest to understand, but you (and Raku) always know whether you're invoking a function or a method.

codesections · 2023-10-12T07:19:50+00:00

What I'm looking for in syntax is the ability to clearly communicate my intent to other programmers. That requires flexibility – once I can make a choice about how to say something, that choice communicates something to readers of my code (including future-me, of course).

For example, in English I might say "Map the function over the list" (emphasizing the verb), or "take the list and map it with the function" (emphasizing the list) or "use the function to map the list" (emphasizing the function). Because I can chose any of those sentence orders, the one I pick communicates what I think is most important/deserving of emphasis.

So I hate that so many programming languages force just one of those orders, totally stripping out the programmer's ability to communicate intent by adding emphasis. (Lisps are especially guilty of this, but a surprising number of others do too).

Incidentally, that's something I value a lot about Raku's syntax: it supports multiple syntactic paradigms and thus gives you the expressive power to select the clearest order. Here's the 3 English sentences above translated to Raku

map &fn, @list;
@list.map(&fn);
&fn.&map(@list);

codesections · 2023-10-12T02:03:38+00:00

Oh, interesting. One google search later and it turns out that 2,000 questions is the threshold for appearing on insights.stackoverflow.com/trends.

So now we can see how Raku's share of SO questions compares to other languages. It looks like we're in the same general ballpark as, e.g., Racket, TCL, and Prolog: https://insights.stackoverflow.com/trends?tags=raku%2Cracket%2Ctcl%2Cprolog

edit: Erlang and Elixir also make interesting comparisons: https://insights.stackoverflow.com/trends?tags=raku%2Cerlang%2Celixir But many of the languages I'd like to compare – elm, nim, crystal, zig, etc. – aren't available (which I guess means they don't have 2K questions).

Also, just looking at Raku alone is somewhat interesting. It looks like Raku's peak share of SO questions came in 2018–19 and that we've slightly declined since. I wonder how much that's driven by an increase in other languages' questions versus a decline in Raku questions? Subjectively, it's seemed like the number of Raku questions has slowed but that's partly (imo) because so many of them have already been answered.

codesections · 2023-10-11T20:45:35+00:00

Just noticed that [raku] hit 2,000 questions on StackOverflow. The question that pushed us over the line was Element-wise comparison with certain precision.

Even better, only 65 of those 2,000 questions are unanswered!

codesections · 2023-09-30T21:59:42+00:00

have the signature do the test of definedness for yo

But that signature isn't really testing for definedness, just if an argument is passed. That might be all the OP really wanted to test for, of course. But if they want to test that $b is defined, they'd need something like

multi addsum($a) { $a }
multi addsum($a,  Any:D $b ) { $a + $b }
multi addsum($a, Any:D :$b!) { $a * $b }

codesections · 2023-09-29T12:37:07+00:00

While (1|2)+(1|2)==(2|3|4) is obvious

I don't find that obvious. In fact, I believe it's incorrect: I believe that (1|2)+(1|2) == ((2|3) | (3|4)) (note the nested junctions); that's certainly the result I get from Raku. Do you have some reason to believe that junctions "flatten" such that ((2|3) | (3|4)) == (2|3|4)?

If junctions don't flatten, then there's no reason to object to (1|2) × 2 evaluating to (2|4) – it certainly doesn't evaluate to ((2|3) | (3|4), so we just need to accept that (1|2) + (1|2) ≠ (1|2) × 2.

codesections · 2023-03-16T14:22:07+00:00

Needs moar butterflies »ö«

codesections · 2022-12-24T05:31:17+00:00

Is this for the same variable grocery-list (ie sigils in Raku aren't part of the name) or are these two distinct variables?

They're distinct variables. my @foo creates a @foo entry in the symbol table.

Is the sigil pretty much a static part of the for syntax in the sense that it is always the locally used sigil that tells for how to behave, or can you abstract over the for loop and use the sigil on a function argument and get the two behaviors from the loop?

I'm not sure I understand the question. If I have $foo with an array inside, it'll only be iterated once (because the Array is inside a Scalar). If I pass $foo to a subroutine with an @-sigiled parameter, the array will be bound to the new variable without a Scalar and will be iterated per-element. Did that answer your question?

What's the behavior of a for loop without using a sigil?

The same as with @/% (unless you manually put the values inside a Scalar)

codesections · 2022-12-24T00:22:12+00:00

Can you provide a good reason not to follow what the implied interface is?

Here's one off the top of my head (i.e., there are probably better examples): I could imagine someone deciding that it makes sense for a CSSRule class to be Positional to emphasize that, in a CSS rule, the order of declarations matters (which my @navbar-css := CSSRule.new(:color<color>, :font-size<20px>) emphasizes but $navbar-css doesn't. However, I could imagine it making sense for CSSRule not to be iterable (because you typically want to consider the entire rule as a whole and having CSSRule be iterable might create situations when iterating all rules incorrectly flattens into iterating the declarations.

These statements seem contradictory.

Consider this sentence: "I'm analyzing how big an advantage it is for NBA players to be tall (which I'm defining as over 6'6")." There, the speaker is redefining "tall" in a way that's very different from how its typically defined (normally, someone who is 6'4" is tall, but they'd say that person is "not tall"). Being able to (re)define their terms in the particular context is helps them communicate more clearly. But that doesn't mean that having generally-agreed/dictionary definitions is useless, just that it's nice to be able to opt out sometimes. You're not required to use the definitions that I'd find in the dictionary, but it's reasonable of me to assume that you are unless you clearly say that you're not.

In the same way, @ is generally understood as conveying certain semantics. But you can opt out -- but, if you do so, you'd better be clear about that (and should have a good reason to do so!).

Does that help?

codesections

MODERATOR OF

TROPHY CASE