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)
Programming is not just a matter of slinging syntax at a problem. Good programmers need to develop a mental model of how a language works.
Needing to do geometric sequences as syntax like that is clearly a parlor trick, a marginal use case. What goes through a good programmer's mind, with experience of getting burned by such things over the years, is "If Raku implements this parlor trick, what other ones does it implement? What other numbers will do something I didn't expect when I put them in? What other patterns will it implement?"
Yes, you can read the docs, and learn, but we also know this interacts with all sorts of things. I'm not telling you why you should be horrified, I'm explaining why on first glance this is something that looks actually quite unappealing and scary to a certain set of programmers.
It actually isn't my opinion either. My opinion isn't so much that this is scary on its own terms, but just demonstrates it is not a language inline with any of my philosophies.
It's a parlor trick because something like "1, * × 2 ..." is much more sensible. Heck, it isn't even longer, if we're talking about saving keystrokes. It's still more syntax than I'm looking for from a language, but "initial, update rule, continue infinitely" does not give me that immediate "oh wtf, what other magic is going to happen with other values?" reaction I describe from trying to divine update rules from raw numbers.
It is also immediately obvious how to use this for other patterns, immediately obvious how to compose it, and just generally experiences all the benefits things get from not being special cases.
> 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.
Yea, I think he has a knack for that. If you want some more I recommend a talk he gave a few years back called “Three Little Words” <https://www.youtube.com/watch?v=e1T7WbKox6s>.
Damian is an excellent writer and communicator for sure. But I don't know if it answers the question of what you would use these features in Raku for. If one wanted to compute e to higher precision, I feel like one would use a DSL. But we also don't need to compute e presently.
If you can read Lisp (Scheme) syntax, I think SICP [0] has the clearest demonstration of the utility of lazy streams. The problem it presents (calculating pi) is, admittedly, rather academic; but the concept of having values that evolve over "time" as first-class entities that you can abstract over is practically useful. I think that all of reactive programming (React, Angular, etc) is closely related to this idea (perhaps even originates from it), although the implementation and applications differ.
It's a long and effortful read, but the payoff is worth the effort.
EDIT: I think the Perl article posted in a sibling comment uses essentially the same example (but for calculating e instead of pi), although I only skimmed it.
I hadn't realized that SICP covered using lazy streams for calculating pi. That reminds me of this article I read recently about using lazy lists in Haskell to calculate pi by means of a few different algorithms.
I've heard that the best way to solve a hard problem is to create a language in which solving that problem would be easy.
Basically creating a Domain Specific Language.
Raku isn't necessarily that language. What it is, is a language which you can modify into being a DSL for solving your hard problem.
Raku is designed so that easy things are easy and hard things are possible. Of course it goes even farther, as some "hard" things are actually easy. (Hard from the perspective of trying to do it in some other language.)
Lets say you want a sequence of Primes. At first you think sieve of Eratosthenes.
Since I am fluent in Raku, I just write this instead:
( 2..∞ ).grep( *.is-prime )
This has the benefit that it doesn't generate any values until you ask for them. Also If you don't do anything to cache the values, they will be garbage collected as you go.