lizmat

> It builds a lookup table of grapheme clusters, and represents them in memory as negative i32s.

Only for those grapheme clusters that do not have a representation in Unicode!

Also, these negative i32s are really an implementation detail.

> but O(1) access to each grapheme is less important

Unless you want regexes to be a. correct in the unicode world, and b. be performant

Check out https://rakudoweekly.blog/blog-feed/

That's exactly what the Raku Programming Language does. Except that the "x" is represented by "*", so it reads:

    grep(*.price < 10)

This is referred to as "Whatever-currying": https://docs.raku.org/type/Whatever*

The Raku programming language has, with some tweaks:

    data.store.book.grep(*.price < 10).map(*.title)

Although personally I would write that as:

    data.store.book.map: { .title if .price < 10 }

which combines the filter / map into a single operation.

https://raku.org

In Raku, if you want to go typed, you can! It's called "gradually typed".

my Int $a = 42; # ok

my Int $a = "foo"; # Type check failed in assignment to $a; expected Int but got Str ("foo")

Maybe a less ambitious plan would be to convert all of the examples in it to Raku. That would at least be a less daunnting task.

None that I know of.

Also, I'm unsure about MJD's feelings about adapting it to a Raku version.

At one point I started writing a book about Raku for Perl programmers.

For various reasons, I did not finish that: but what did got written, wound up as a 24-part blog series on dev.to: https://dev.to/lizmat/series/24075

Since commercial development has stopped (see https://commaide.com/discontinued ) the Edument Team has released the final commercial version of the Comma IDE for the Raku Programming Language for free.

The source code will be made available to allow community development of this project in the future.

When was the last time you checked performance? :-)

Which is called the Raku Programming Language (#rakulang) since 2019.

    $ raku -e 'say 9999999999999999.0 - 9999999999999998.0'
    1

https://raku.org

It's actually

    a = x ?? y !! z

And that's because a single : is used for many other semantics in the Raku Programming Language. And ?? and !! standout better in code.

https://docs.raku.org/language/operators#infix_??_!!

Please note that in Raku, you can also use a role as a class without having to create a class, through a process called auto-punning.

https://docs.raku.org/language/typesystem#Auto-punning

I can assure you, nobody in the Perl crowd is doing any Raku.

Almost in the Raku Programming Language, bit with a single |

    states.includes('VALID' | 'IN_PROGRESS')

is effectively the same as:

    states.includes('VALID') || states.includes('IN_PROGRESS')

See https://docs.raku.org/type/Junction

I assume this is directed at the author of rak, so I'll answer.

$x ~~ $y is basically syntactic sugar for $y.ACCEPTS($x). Using ~~ involves an additional subroutine call, so there's a short-term efficiency issue (as in programs running more than a second or so the extra call will have been inlined).

But personally, I like the verbosity of $y.ACCEPTS($x) as it reads better for me, having been burnt by ~~ semantics in Perl, which was symmetrical.

$ rak '{.contains: "foo1" & "foo2" & "foo3" & "foo4" &"foo5"}'

This actually shows one of the secret powers of the Raku Programming Language: Junctions https://docs.raku.org/type/Junction

Alternately one could express this as:

$ rak '{.contains: <foo1 foo2 foo3 foo4 foo5>.all}'

Or using whatever currying: https://docs.raku.org/type/Whatever

$ rak '*.contains: <foo1 foo2 foo3 foo4 foo5>.all'

FWIW, on some MacBook Pro keyboards, the § is right next to 1:

https://keyshorts.com/blogs/blog/37615873-how-to-identify-ma...

> likely need to write an entirely new regex engine

Indeed.

Also, it should be noted that the Raku Regex engine is not a state machine as such. The regex "slang" in Raku, is basically just another way to write code. Code that uses some state machine primitives underneath, for sure, but still code.

A grammar in Raku is nothing other than a class in which the methods are codegenned using the regex syntax. But a class nonetheless, which can also have attributes and "proper" methods.

This gives the Raku regex engine the flexibility needed to be able to parse Raku source code, and generate executable bytecode from that.

> It does very likely have enormous implications for performance though.

Well, but that's only one of the reasons why rak is a lot slower. There's something else going on, but I currently don't have the mindset to investigate this deeply.

- Support for NFG (Normalization Form Grapheme), which e.g. means that you only need to specify 'é' if you want to look for an 'é', and not have to worry about whether the text you're searching in, consists of the single codepoint 'é', or that it has the decomposed version.

- support for --ignoremark, which means you 'e' will match any accented 'e', such as éëêèęėē.

Author of App::Rak here:

> I'm not totally clear on what kind of filtering `rak` does by default

By default, rak search all of the files that look like text, by reading the first 2K (if I remember correctly) and using some algorithm to determine "binaryness".

> I realize features and an expressive language is your main goal

Indeed.

> I wanted to see what it looked like from a perf perspective

The performance times you've given here, coincide with my findings. Which for the "sixteenth.txt" surprises me: a bare loop in Raku reading that file line-by-line finishes in 8 seconds for me. Which would be one order of magnitude less than the search result. Still not in `rg`'s ball park, but speed wasn't a big concern for me. But 8 -> 48 seconds is a pretty big difference, so I guess it's back to the drawing board for me on that one :-)

Timing wise, it could very well have influenced Larry Wall at the time!

An introduction to the Raku Programming Language coming from legacy Perl.

> Where do the angle brackets come in?

The angle brackets are syntactic sugar for word quoting.

    <a b c>

is syntactic sugar for:

    ("a", "b", "c")

They can be used standalone. Or as postcircumfix on hashes:

    %foo<a>      # the value of key "a" in hash %foo
    %foo<a b c>  # the values of keys "a", "b", "c" in hash %foo

There's a lot more to it than that, but that's the gist of it.

https://docs.raku.org/language/quoting#Word_quoting:_%3C_%3E

> Lists are given to the reader in angle brackets and printed in parentheses, or at least that's how it looks. I suppose the other possibility is that these are actually different types

They are different types:

[1,2,3] is an array with mutable elements that can be expanded, shortened (1,2,3) is a list with immutable elements of fixed length

> find an example of anyone actually using it

A common example of signature introspection is when a routine accepts a lambda as a parameter, and adapts its function depending on the number of arguments the lambda expects (the arity: &foo.signature.arity, see https://docs.raku.org/syntax/Arity).

Two examples:

The "sort" function optionally accepts a lambda: if that takes one argument, then a Schwarztian transform will be done under the hood. If it takes two, then the lambda will be used as the comparator.

The "map" function expects a lambda. Depending on the number of arguments it takes, it will take that many arguments each time from the iterator it runs on.

say (1..12).map( -> $a, $b, $c { $a - $b * $c } ) # (-5 -26 -65 -122)

Perhaps. But that will become very difficult indeed.

Because in Raku, grammars are just a different way to write code. Grammars are really just specialized classes. And tokens / rules / regexes are just specialized methods. It all compiles down to bytecode, rather than something you can feed a statemachine.

This has several advantages: if a grammar doesn't provide functionality you need, you can write it in Raku code as part of the grammar.

It also means that when you improve execution of the bytecode, you will also improve the performance of grammars and regexes.

Finally: Raku grammars are very powerful. They are used to parse the Raku language itself. Which is a testament to its power. But also brings a whole set of challenges for the core developers :-)

`INIT $RAT-OVERFLOW = CX::Warn` will produce a warning whenever a switch to Num happens.

`INIT $RAT-OVERFLOW = Exception` will throw an exception whenever a switch to Num would happen.

If you want to define your own behaviour, you can. For instance:

class ZeroOrInf { method UPGRADE-RAT(Int $nu, Int $de) { $nu > $de ?? Inf !! 0 } } INIT $*RAT-OVERFLOW = ZeroOrInf

would either convert the value to `Inf`if too large, or to `0` if too small.

And for 1.5 years now, you can have the FatRat behaviour by simply adding `INIT $*RAT-OVERFLOW = FatRat` to your program.

Newer versions of Rakudo allow you to tune this behaviour dynamically through the $*RAT-OVERFLOW dynamic variable (which defaults to Num for the described behaviour).

See: https://docs.raku.org/language/variables#$*RAT-OVERFLOW*