Raku's arrow operators lack Unicode equivalents

[codesections]

Raku provides Unicode versions of many operators – basically whenever there is a sensible suitable Unicode equivalent. However, Raku doesn't provide Unicode alternatives to any of Raku's arrow operators (or operator-like pieces of syntax). But Unicode provides a ton of arrow symbols, so it would be easy for to add Unicode equivalents.

More specifically, there are no Unicode equivalents to any of the following arrows.

my &pointy-block = -> $_ { $_ + 1 };
sub return-value($_ --> Int) { $_ + 1 }
my $left-feed = 1 ==> sum(2);
my $right-feed = (sum(2) <== 1);

[codesections]

Proposed solution: Raku v6.e should provide the following Unicode operators:

Symbol	Code	Equivalent to
→	U+2192	->
⟶	U+27F6	-->
⇒	U+21D2	==>
⇐	U+21D0	<==

Using these symbols, the code above could be rewritten as:

my &pointy-block = → $_ { $_ + 1 };
sub return-value($_ ⟶ Int) { $_ + 1 }
my $left-feed = 1 ⇒ sum(2);
my $right-feed = (sum(2) ⇐ 1);

[TimToady]

I'd use the long variants of the double barreled arrows: ⟸ and ⟹.

Larry

On Wed, Sep 27, 2023 at 11:39 AM Daniel Sockwell @.***> wrote:

Proposed solution: Raku v6.e should provide the following Unicode operators: Symbol Code Equivalent to → U+2192 -> ⟶ U+27F6 --> ⇒ U+21D2 ==> ⇐ U+21D0 <==

Using these symbols, the code above could be rewritten as:

my &pointy-block = → $ { $ + 1 };sub return-value($ ⟶ Int) { $ + 1 }my $left-feed = 1 ⇒ sum(2);my $right-feed = (sum(2) ⇐ 1);

— Reply to this email directly, view it on GitHub https://github.com/Raku/problem-solving/issues/389#issuecomment-1737900667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABHSYWG4MKHJSDADGSPNHLX4RXFJANCNFSM6AAAAAA5JZOTO4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[codesections]

I'd use the long variants of the double barreled arrows: ⟸ and ⟹.

Larry

Fair enough. I've updated the table below.

Out of curiosity, why do you prefer the long variants? My thinking when I suggested the short variants was that the only reason the operator is <== was because <= is already taken by the less-than-or-equal-to operator. But since ⇐ doesn't clash with ≤, I figured it'd be better to save the horizontal space. But I don't feel strongly on the matter and ⟸/⟹ are fine with me.

---

Symbol	Code	Equivalent to
→	U+2192	->
⟶	U+27F6	-->
⟹	U+27F9	==>
⟸	U+27F8	<==

Using these symbols, the code from the OP could be rewritten as:

my &pointy-block = → $_ { $_ + 1 };
sub return-value($_ ⟶ Int) { $_ + 1 }
my $left-feed = 1 ⟹ sum(2);
my $right-feed = (sum(2) ⟸ 1);

[lizmat]

@TimToady Happy Birthday! :-)

[raiph]

Raku provides Unicode versions of many operators – basically whenever there is a sensible Unicode equivalent.

I'm suspicious of words like "sensible". Suitable is about the same, but seems like a, er, more suitable word for this scenario because it doesn't have the problems "sensible" has. (Of course, it has its own problems, but I'm going with it.)

I'd say Raku provides Unicode versions of features whenever a Unicode equivalent is a suitable thing to have, and there's a suitable Unicode equivalent, and there's consensus it has sufficient upsides and doesn't have significant downsides.

---

FWIW, to me:

→

looks far too similar to:

⟶

I grant that that's "cheating". I'll try not to cheat.

---

In this monospaced font the difference is much clearer:

The quick brown fox → jumped over the aard while it ⟶ varked.

But I still think they are way too similar.

---

There are some other issues I think might be considered relevant. For example:

• Ideally we would cover the <-> case too.

• There's an opportunity here to help avoid some cognitive dissonance among non-Rakoons that Raku's use of -> (and to a lesser extent, -->) have created. Many PLs use -> as part of type expressions, eg a -> b, and some support → or ⟶ as an alias. I can see it helping if we choose sufficiently different standard Unicode aliases -- different from each other, and from what other PLs have adopted.

---

Maybe ⤍ for -->? It feels like it needs to be mentioned, but imo it's still far too samey, and I don't much like it anyway.

---

Let me suggest something radical:

• ⭷ declares a lambda. Alias of ->.

• ⭹ declares a lambda with all parameters being read-write. Alias of <->.

• ⭸ declares a return value. Alias of -->.

This means you get a clear visual pill for signatures: ⭷ $a, $b, $c ⭸ Nil { }.

[codesections]

I'm suspicious of words like "sensible". Suitable is about the same, but seems like a, er, more suitable word

Good point; I've edited the OP.

Ideally we would cover the <-> case too

Ah, I felt like I was forgetting something. The obvious (i.e., non-radical ☺) option there would be ↔ (U+2194).

You make a good point about the similarity of → and ⟶. But I'd probably skip past the double-dashed arrow (⤍) and go to the triple-dashed one ⤏ (U+290F). ⤏ and → seem likely to be distinct in most any font. There's also ⟼ (U+27FC) or ⭬ (U+2B6C), but I don't like them as much.

Let me suggest something radical

I see where you're coming from with that, and I agree that -> (and thus →) are a bit of a WAT for Rakoons with backgrounds in certain programming languages. But I can't get fully on board with that proposal for two reasons:

1. It would be the only area where our Unicode operators break strongly from the ASCII representation. I don't think the potential cognitive savings for Rakoons from some PLs would be worth that inconsistency – especially since they'd need to learn the ASCII operators anyway (to read others' code).
2. I don't find the visual nearly as clear as you do. In fact, I think I'd prefer them flipped: ⭸ $a, $b, $c ⭷ Nil { } – my logic would be that I'm putting $a, $b, and $c down into the function and getting Nil back up from it. (I guess my mental metaphor is based on the call stack?).

Imo, they'd need to add significant clarity to overcome the downside of the inconsistency they add. And, at least to me, they don't.

So all of that brings the proposal to:

Symbol	Code	Equivalent to
→	U+2192	->
↔	U+2194	<->
⤏	U+27F6	-->
⟹	U+27F9	==>
⟸	U+27F8	<==

Using these symbols, the code from the OP could be rewritten as:

my &pointy-block = → $_ { $_ + 1 };
my &rw-pointy-block = ↔ $_ { $_ + 1 };
sub return-value($_ ⤏ Int) { $_ + 1 }
my $left-feed = 1 ⟹ sum(2);
my $right-feed = (sum(2) ⟸ 1);

[ab5tract]

I think the latest proposal nails it.

[jubilatious1]

@raiph said:

Let me suggest something radical:

⭷ declares a lambda. Alias of ->.

⭹ declares a lambda with all parameters being read-write. Alias of <->.

⭸ declares a return value. Alias of -->.

Characters aren't showing up in my browser (Safari).

[jubilatious1]

Maybe not a bad idea to have arrows consistent (visually consistent at least) with other languages, e.g. R-project?

https://stackoverflow.com/a/51548423

(The SO answerer is a Mathematics Professor at McMaster Univ.: https://math.mcmaster.ca/~bolker/)

Although a similar Unicode question has gone unanswered:

https://stackoverflow.com/questions/65351494/how-do-i-make-a-unicode-arrow-as-a-character-variable-in-r

Some people apparently are using fonts with ligatures (instead of true Unicode characters):

https://www.reddit.com/r/RStudio/comments/uxgkvf/new_arrow_symbol_in_rstudio/

Others have coded keyboard shortcuts:

https://community.rstudio.com/t/key-shortcut-for/15949

[duncand]

My general thought on the matter of Unicode is that less is more. We should only be providing Unicode versions of ASCII things where there is a clear benefit. To me the best reason to use Unicode is to faithfully represent real-world or historical expressions of things, for example using the "real" math or logical or set or whatever operators that are customarily used by professionals in their field in literature. Whereas, operators that were invented for Raku and have no analogy in existing fields shouldn't be gaining Unicode alternatives just because they are lookalikes to the ASCII versions. Especially considering Unicode offers zillions of lookalikes to almost anything, how do we choose, and what value do they bring? Unless the syntax here is meant to evoke a pre-existing thing we want to match, I feel adding these Unicode variants may be gratuitous.

[duncand]

To further clarify my previous comment, the best time to use Unicode is when Unicode contains the IDEAL versions of symbols that we wanted all along, where the ASCII versions were only created as a degraded alternative because they are more easily available or compatible or easy to type. But symbols that were created as ASCII in the first place based on context of other ASCII symbols and not originally created as a degraded alternative of a Unicode ideal in the first place, we should be more careful about adding Unicode lookalikes in the first place, and justify them as an actual improvement that people would actually prefer to use in code, rather than existing just to exist. Not every ASCII symbol needs a Unicode alternative.

[frou]

Framed that way, the ASCII Art arrow -> is surely one of the most obvious examples of "degraded" representations in the whole of programming.