>> 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.

That concept of "strange consistency" reminds me of my experience writing Clojure, for some reason.

Nil punning in Clojure gives you that kind of experience, for example. Things that would break in other languages, just "work as you'd expect them" in Clojure (except when you drop down to host primitives, and then nils don't behave nicely anymore). In general, it makes for a really pleasant dev experience, I find.

I don't think Perl is really that hard to learn. It does have a few traps for people new to the language though.

Raku on the other hand is easy to learn. Of course it is so easy to learn that knowing another language, any other language, can make it more difficult to fully grasp. That is because Raku is strangely consistent.

Most languages have a set of syntaxes for different actions. Raku has a set of features, and the syntax mostly just falls out from that.

When someone who knows another language tries to learn Raku they naturally translate what they already know to Raku features. That will only get you a surface level understanding of the language. No other language is really comparable.

Raku also has a new view of regexes. In Raku a regex is just a DSL for matching text. So rather than bolt on feature after feature like other languages have done it allows you to embed regular Raku code for situations where that is easier. You can also combine them using grammars (a type of class) to get a full parser out of several parts.

In fact the grammar feature in Raku is the only one that is powerful enough to parse Raku easily. Part of that has to do with the ability to mutate the language.

It has been said that the best way to solve a programming problem is to create a language in which solving the problem is easy. Raku, using that ability, allows you to do that easily.

The `but` keyword takes an instance and something to mix into it.

So you can say something like this:

    0 but True

---

Since `True` is a `Bool` it automatically creates a role that has a method `Bool` that returns `True`.

    my $role = role { method Bool { True }}

You can do that manually if you want.

    0 but role { method Bool { True }}

---

It creates a new subclass of Int and mixes in the role.

So:

    0 but True

Is roughly equivalent to:

    do {
      my constant but-true = anon role { method Bool { True }}
      my $class = anon class :: is Int does but-true {}

      $class.new( 0 )
    }

It was originally for helping to organize Perl events. It acted as an entity that could enter into contracts for insurance and rental purposes.

It was extended to have grants among other things.

Larry Wall has historically only really been influential on the design of the language. So it was not taken away, he just has rarely done anything outside of that.

I think it matters who your audience is.

If your audience is mostly programmers then just use `*`

If your audience is physicists or mathematicians then `×` or `·` may be a better fit.

When turning a math expression into code, it is often handy if the code looks a lot like the expression. Even better if you can just copy and paste it. It's hard to translate an expression wrong if you aren't translating it at all.

They'd probably just define each of the segments separately and require you to use a zero width joiner.

Raku

    say π ≤ 3+⅘ ≤ τ
    # True

    say π² ÷ 4
    # 2.4674011002723395

I remember reading an article that the width of railway track was set by the width of chariots.

I don't remember much about the article except it ended with some quip about the width of a car was determined by a couple of horses asses.

In Raku you can also use × (U+D7) for multiplication

    # this assumes that ϕ, ψ, and θ have already been set

    my \cϕ = ϕ.cos; my \sϕ = ϕ.sin;
    my \cψ = ψ.cos; my \sψ = ψ.sin;
    my \cθ = θ.cos; my \sθ = θ.sin;

    my \alpha = [ cψ×cϕ−cθ×sϕ×sψ,   cψ×sϕ+cθ×cϕ×sψ,   sψ×sθ;
               −sψ×cϕ−cθ×sϕ×cψ,  −sψ×sϕ+cθ×cϕ×cψ,   cψ×sθ;
                sθ×sϕ,           −sθ×cϕ,            cθ];

I'm not sure if using × helps or hurts in this case since I'm not really experienced in this area.

These all work because Unicode defines ϕψθ as "Letter lowercase"

    say "ϕψθ".uniprops;
    # (Ll Ll Ll)

---

I would like to note that I used the Unicode "Minus Sign" "−" U+2212 so that it wouldn't complain about not being able to find a routine named "cϕ-cθ". (A space next to the "-" would have also sufficed.)

> × (U+D7) for multiplication

Blech; looks like a letter and normalizes cross products. Better to use "·" (U+B7)[0]:

  alpha = [ cψ·cϕ−cθ·sϕ·sψ,  cψ·sϕ+cθ·cϕ·sψ,  sψ·sθ;
           −sψ·cϕ−cθ·sϕ·cψ, −sψ·sϕ+cθ·cϕ·cψ,  cψ·sθ;
            sθ·sϕ,          −sθ·cϕ,           cθ];

Minus sign is a nice-to-have, though.

0: Also "∧" (U+2227, wedge), the real other vector product[1], but that doesn't matter for scalar multiplication.

1: http://en.wikipedia.org/wiki/Wedge_product

It would be easy to just make `·` an alias. Then that code would work.

  my &infix:< · > = &infix:< × >;

(After all `×` itself is just an alias of `*` in the source for Rakudo.)

If you need more control you can write it out

  sub infix:< · > (+@vals)
    is equiv(&[×])       # uses the same precedence level etc.
    is assoc<chaining>   # may not be necessary given previous line
  {
    [×] @vals            # reduction using infix operator
  }

I made it chaining for the same reason `+` and `×` are chaining.

---

I don't know enough about the topic to know how to properly write `∧`.

It looks like it may be useful to write it using multis.

  # I don't know what precedence level it is supposed to be
  proto infix:< ∧ > (|) is tighter(&[×]) {*}

  multi infix:< ∧ > (
    Numeric $l,
    Numeric $r,
  ) {
    $l × $r
  }

  multi infix:< ∧ > (
    Vector $l, # need to define this somewhere, or use List/Array
    Vector $r,
  ) {
    …
  }

If it was as simple as just a normal cross product, that would have been easy.

  [[1,2,3],[4,5,6]] »×« [[10,20,30],[40,50,60]]
  # [[10,40,90],[160,250,360]]

  # generate a synthetic `»×«` operator, and give it an alias
  my &infix:< ∧ > = &infix:< »×« >;

  [[1,2,3],[4,5,6]] ∧ [[10,20,30],[40,50,60]]
  # [[10,40,90],[160,250,360]]

Of course, I'm fairly confident that is wrong.

Technically it is MoarVM that handles graphemes as synthetic codepoints.

We call it NFG for Normalized Form Grapheme.

The JVM and JavaScript backends currently use the built-in string handling features. Which means that they are just as broken as the rest of the code running on them.

---

Of further note, you can use ignorecase in regexes to match "baffle".

    "baffle" ~~ /:ignorecase  BAFfLE  /;