I imagine this could be understood as making use of a monad. Right?

The main problem with generalised regexes is that you can't match them in linear time worst-case. I'm wondering if this is addressed at all by Raku.

Why are they called regular expressions if they can parse non-regular languages?

I don't think we disagree here. To clarify, my statement about using "actual parsers" over regexes was more directed at my own library than Raku. Since I had just posted a link on how to "parse" media types using my library, I wanted to immediately follow that with a word of caution of "But don't do that! You shouldn't be using (traditional) regexes to parse! They are the wrong tool for that. How unfortunate it is that most languages have a super simple syntax for (traditional/PCRE) regexes and not for parsing." I had seen in the article that Raku had some sort of "grammar" concept, so I was kind of saying "oh it looks like Raku may be tackling that to."

Hopefully that clarifies that I was not necessarily making any statement about whether or not to use Raku regexes, which I don't pretend to know well enough to qualify to give advice around. Just for the sake of interesting discussion however, I do have a few follow up comments to what you wrote:

1. Aside from my original confusing use of the term "regexes" to actually mean "PCRE-style regexes", I recognize I also left a fair amount of ambiguity by referring to "actual parsers". Given that there is no "true" requirement to be a parser, what I was attempting to say is something along the lines of: a tool designed to transform text into some sort of structured data, as opposed to a tool designed to match patterns. Again, from this alone, seems like Raku regexes qualify just fine.

2. That being said, I do have a separate issue with using regexes for anything, which is that I do not think it is trivial to reason about the performance characteristics of regexes. IOW, the syntax "doesn't scale". This has already been discussed plenty of course, but suffice it to say that backtracking has proven undeniably popular, and so it seems an essential part of what most people consider regexes. Unfortunately this can lead to surprises when long strings are passed in later. Relatedly, I think regexes are just difficult to understand in general (for most people). No one seems to actually know them all that well. They venture very close to "write-only languages". Then people are scared to ever make a change in them. All of this arguably is a result of the original point that regexes are optimized for quick and dirty string matching, not to power gcc's C parser. This is all of course exacerbated by the truly terrible ergonomics, including not being able to compose regexes out of the box, etc. Again, I think you make a case here that Raku is attempting to "elevate" the regex to solve some if not all of these problems (clearly not only composable but also "modular", as well as being able to control backtracking, etc.) All great things!

I'd still be apprehensive about the regex "atoms" since I do think that regexes are not super intuitive for most people. But perhaps I've reversed cause and effect and the reason they're not intuitive is because of the state they currently exist in in most languages, and if you could write them with Raku's advanced features, regexes would be no more unintuitive than any other language feature, since you aren't forced to create one long unterminated 500-character regex for anything interesting. In other words, perhaps the "confusing" aspects of regexes are much more incidental to their "API" vs. an essential consequence of the way they describe and match text.

3. I'd like to just separately point out that many aspects of what you mentioned was added to regexes could be added to other kinds of parsers as well. IOW, "actual parsers" could theoretically parse Raku, if said "actual parsers" supported the discussed extensions. For example, there's no reason PEG parsers couldn't allow you to fall into dynamic sub-languages. Perhaps you did not mean to imply that this couldn't be the case, but I just wanted to make sure to point out that these extensions you mention appear to have much more generally applicable than they are perhaps given credit for by being "a part of regexes in Raku" (or maybe that's not the case at all and it was just presented this way in this comment for brevity, totally possible since I don't know Raku).

I'll certainly take a closer look at the full Raku grammar stuff since I've written lots of parser extensions that I'd be curious have analogues in Raku or might make sense to add to it, or alternatively interesting other ideas that can be taken from Raku. I will say that RakuAST is something I've always wanted languages to have, so that alone is very exciting!

Here is one way:

    use HTTP::UserAgent;
    use JSON::Fast;

    my $url = 'https://api.coindesk.com/v1/bpi/currentprice.json';

    my $ua = HTTP::UserAgent.new;

    my $total-time = 0;
    loop {
        my $response = $ua.get($url);
        if $response.is-success {
            my $data = from-json $response.content;
            my $rate = $data<chartName>;
            say "Current chart name: $rate";
            #last if $rate eq 'Bitcoin';
            last if $total-time ≥ 16;
        }
        else {
            say "Failed to fetch data: {$response.status-line}";
        }
        sleep 3; # Poll every 3 seconds
        $total-time += 3;
    }

Same. And it's a bit funny because I'm usually against unnecessary complexity, and here's a language that seems to have embraced it and become a giant castle of language features that I could spend weeks studying.

Maybe it's because Raku's features were actually well thought-out, unlike the incidental "doesn't actually buy me anything, just makes the code hard to deal with" complexity I have to deal at work day in and day out.

Maybe if Java had a few of these features back in the day people wouldn't've felt the need to construct these monstrous annotation soup frameworks in it.

Some of them seem ok, e.g. ignoring whitespaces in regex by default is a great move, and the `` as a shorthand single lambda argument is neat.

But trust me if you ever have to actually work* with them you will find yourself cursing whoever decided to riddle their code with <<+>>, or the person that decided `* + ` isn't the same as `2 *` (that parser must have been fun to write!)

yeah, you're right.

your entire comment is syntactically valid raku, or can be made so, because raku syntax is so powerful and flexible.

raku grammars ftw!

https://docs.raku.org/language/grammars

https://docs.raku.org/language/grammar_tutorial

;)

even that last little fella above, is or can be made syntactically valid.

Sure, but the fact that weird stuff is possible means that someone, at some point, will try to use it in your codebase. This might be prevented if you have a strong code review culture, but if the lead dev in the project wants to use something unusual, chances are no one will stop them. And once you start...

Many of the features that make Perl harder to write cleanly have been improved in Raku.

Frankly I would absolutely love to maintain a Raku codebase.

I would also like to update a Perl codebase into being more maintainable. I'm not sure how much I would like to actually maintain a Perl codebase because I have been spoiled by Raku. So I also wouldn't like to maintain one in Java, Python, C/C++, D, Rust, Go, etc.

Imagine learning how to use both of your arms as if they were your dominant arm, and doing so simultaneously. Then imagine going back to only using one arm for most tasks. That's about how I feel about using languages other than Raku.

its not that reading perl is hard, the _intent_ of the operations of often hard/unclear.

Yes its nice to write dense fancy code, however, something very boring to write like PHP is a lot of "loop over this bucket and do something with the fish in the bucket, afterwards, take the bucket and throw it into the bucket pile" that mirrors a 'human follows these steps' type.

Perl reminds me of that job I had writing ANSI MUMPS.

it's extremely fun to write

Then your contrarian phase ends and you regret that you didn’t learn something useful in that time.

It's also quite similar to Thread and MapThread in Mathematica

[flagged]

That's nothing, use it to calculate the sum of range of values

  say [+] 1..10000000000000000000000000000000000000000000

50000000000000000000000000000000000000000005000000000000000000000000000000000000000000

(It actually cheats because that particular operator gets substituted for `sum` which knows how to calculate the sum of a Range object.)

I specified the use case so why "meaningless"? Here's the code:

    Raku
    for 'logs1.txt'.IO.lines -> $_ { .say if $_ ~~ /<<\w ** 15>>/; }

    Python
    from re import search
    with open('logs1.txt', 'r') as fh:
        for line in fh:
            if search(r'\b\w{15}\b', line): print(line, end='')

I believe that it only tries to DWIM with arithmetic and geometric sequences, and gives up otherwise. Of course there’s nothing keeping you from writing a module that would override infix:... in the local scope with a lookup in OEIS.

You get either a compile time instantiated infinite lazy sequence, or a compilation error.

My personal bar for "amount of clever involved" is fairly high when the clever either does exactly what you'd expect or fails, and even higher when it does so at compile time.

(personal bars, and personal definitions of "exactly what you'd expect" will of course vary, but I think your brain may have miscalibrated the level of risk before it got as far as applying your preferences in this particular case)

This has nothing to do with the halting problem. And I have no idea why you think there would be 'terrible consequences'.

  2, 4, 8 ... *

Basically the above becomes

  2, 4, 8, * × 2 ... *

If ... can't deduce the sequence, it will error out.

  2, 4, 9 ... *

  Unable to deduce arithmetic or geometric sequence from: 2, 4, 9
  Did you really mean '..'?
  in block at ./example.raku line 1

> The detecting of increments has been in Perl for ages so that's not new.

But this is detecting that the increment is multiplicative, rather than additive. It might seem like a natural next step, but, for example, I somewhat suspect (and definitely hope) that Raku wouldn't know that `(1, 1, 2...*)` is a (shifted) list of Fibonacci numbers.

These are all very clever, but what's the use case? I'm not saying there isn't one, I just don't know what it is! Not to speak of the dead, but Perl was utilitarian: it was built to solve problems. From my point of view, these are solutions to problems I've never had.

This is a very funny comment given the context.

https://github.com/Raku/problem-solving/pull/89#pullrequestr...

A quote from the Christian Bible Luke 5:36,37

Agreed. The "Perl 6 is a different language" meme was so overdone. To anyone who actually used Perl 5 the continuity was obvious.

I've often thought of Raku as being a lot like the English language. It borrows heavily from other languages.

Of course since Raku has the benefit of an actual designer, it is more cohesive than English.

I’m not sure that I see the connection that you are making here. Can you elaborate?

Also note that in contrast to Bash, Junction is a type.

Regarding their utility, at their most useful level (in my experience), junctions provide for things like:

   $string ~~ “this”|”that”|”other”

   $string eq “this” || $string eq “that” || $string eq “other”

> digressions into discussing Perl

Changing the name to Raku doesn't obliterate Perl 6's history as Larry Wall's successor to Perl 5.

I don't know why you would expect people to pretend that they're unrelated. They aren't.

It has the same whimsy and DWIM of perl, look at Promise having a status of 'kept' or 'broken' which is more fun than 'fulfilled' or 'rejected'. Brings to mind Perl 5's use of bless, calling the filter function 'grep' and local/global variables created with 'my' and 'our'.

Indeed! There's lots of magic even in Perl4, some of it obscure.

Yes, though perl5 is also an incredibly bendable language syntax wise - you can add keywords and operators to the compiler via CPAN modules (our async/await syntax is provided simply by doing 'use Future::AsyncAwait' for example).

Doing High-Order Programming in perl is not something new.

There is a full book about it:

https://en.m.wikipedia.org/wiki/Higher-Order_Perl

Whats nee in Raku is putting them together with other experimental features as first class citizens

>> magic functions—which behave differently on lists-of-scalars vs. lists-of-lists by special default logic ...

That is completely the wrong way to think about it. Before the Great List Refactor those were dealt with the same by most operations (as you apparently want it). And that was the absolute biggest problem that needed to be changed at the time. There were things that just weren't possible to do no matter how I tried. The way you want it to work DID NOT WORK! It was terrible. Making scalars work as single elements was absolutely necessary to make the language usable. At the time of the GLR that was the single biggest obstacle preventing me from using Raku for anything.

It also isn't some arbitrary default logic. It is not arbitrary, and calling it "default" is wrong because that insinuates that it is possible to turn it off. To get it to do something else with a scalar, you have to specifically unscalarify that item in some manner. (While you did not specifically say 'arbitrary', it certainly seems like that is your position.)

Let's say you have a list of families, and you want to treat each family as a group, not as individuals. You have to scalarize each family so that they are treated as a single item. If you didn't do that most operations will interact with individuals inside of families, which you didn't want.

In Raku a single item is also treated as a list with only one item in it depending on how you use it. (Calling `.head` on a list returns the first item, calling it on an item returns the item as if it had been the first item in a list.) Being able to do the reverse and have a list act as single item is just as important in Raku.

While you may not understand why it works the way it works, you are wrong if you think that it should treat lists-of-scalars the same as lists-of-lists.

>> This attempt to fuse higher-order functional programming with magic special behaviors from Perl comes off to me as quixotic.

It is wrong to call it an attempt, as it is quite successful at it. There is a saying in Raku circles that Raku is strangely consistent. Rather than having a special feature for this and another special feature for that, there is one generic feature that works for both.

In Python there is a special syntax inside of a array indexing operation. Which (as far as I am aware) is the only place that syntax works, and it is not really like anything else in the language. There is also a special syntax in Raku designed for array indexing operations, but it is just another slightly more concise way to create a lambda/closure. You can use that syntax anywhere you want a lambda/closure. Conversely if you wanted to use one of the other lambda/closure syntaxes in an array indexing operation you could.

The reason that we say that Raku is strangely consistent, is that basically no other high level language is anywhere near as consistent. There is almost no 'magic special behaviors'. There is only the behavior, and that behavior is consistent regardless of what you give it. There are features in Perl that are magic special behaviors. Those special behaviors were specifically not copied into Raku unless there was a really good reason. (In fact I can't really think of any at the moment that were copied.)

Any sufficiently advanced technology is indistinguishable from magic. So you saying that it is magic is only really saying that you don't understand it. It could be magic, or it could be advanced technology, either way it would appear to be magic.

In my early days of playing with Raku I would regularly try to break it by using one random feature with another. I often expected it to break. Only it almost never did. The features just worked. It also generally worked the way I thought it should.

The reason you see it as quixotic is that you see a someone tilting at a windmill and assuming they are insane. The problem is that it maybe it isn't actually a windmill, and maybe you are just looking at it from the wrong perspective.

> You're making a mistake if you're thinking like that. Applying an operation that generally works on single values over a list of values automatically is an incredibly powerful technique.

Indeed, the defining technique of array programming!

My fundamental objection here it that it is recursive. The non-recursive hyperoperators all have nice clean mathematical definitions. The recursive ones are just weird and ad hoc, at least from the perpective of the underlying mathematical structures.

The operation itself is trivially useful but the operator soup makes me want to run screaming.

You're right. It makes way more sense when you compare it to Numpy.

That's not really the issue here. The problem is they've elevated this super weird recursive looping operation to the level of a built-in operator.

Built-in operators should be reserved for tasks that are extremely common and have obvious behaviours.

This would be more suitable as a function, like

    applyBroadcast([1, [2, 3], 4, 5], [10, 20], +, recursive=true, loop=true)

The reason is that no one cares about your failure to read correctly. It adds nothing to the conversation. (I didn't downvote.)

I didn't downvote, but this is by far not the first time something like that was stated (Raku being similar to Roku).

I know I'm tired of seeing it, I'm sure others are as well.