Skip to content

Instantly share code, notes, and snippets.

@AlexDaniel
Last active March 14, 2017 01:01
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save AlexDaniel/c89bd2786f9b63f31e4c to your computer and use it in GitHub Desktop.
Save AlexDaniel/c89bd2786f9b63f31e4c to your computer and use it in GitHub Desktop.
Save me from Texas

⚠⚠⚠⚠⚠⚠⚠ ↓↓↓ PAGE MOVED ↓↓↓ ⚠⚠⚠⚠⚠⚠⚠

I moved this page to rakudo wiki. A lot of people wanted to add stuff, but gists are not editable. A wiki is a more appropriate place for this kind of stuff. Rakudo wiki is possibly not the best place for it, but for now that will do.

Plus, GitHub gists totally suck when unicode characters are involved. There's also no preview option here. So I'm glad that it is being moved.

⚠⚠⚠⚠⚠⚠⚠ ↑↑↑ PAGE MOVED ↑↑↑ ⚠⚠⚠⚠⚠⚠⚠

Recently Perl 6 got support for various unicode characters (½ ¹ ∞ × ÷, see this link for a full list), but I don't think that we are done. Here is a list of things to think about.

Simple things

≤ ≥ ≠ (✓ in rakudo/rakudo#1032)

These are more or less obvious and a lot of people have wondered why Perl 6 does not support them yet.

Most probably we should, but there comes a good question – isn't it a bit too much? Well, most probably it's not.

See also: https://irclog.perlgeek.de/perl6/2016-01-09#i_11859391

#↓ and #←

So that this:

#| This subroutine does the real work
sub do_raw_magic (
    Spell $s,         #= Which spell to invoke
    *%options         #= How to invoke it
) {...}

Could be written as:

#↓ This subroutine does the real work
sub do_raw_magic (
    Spell $s,         #← Which spell to invoke
    *%options         #← How to invoke it
) {...}

→ { }

Why not allow in pointy blocks?

for ^5 -> $i { say $i } # noo!
for ^5 → $i { say $i } # yeaah!

↔ { }

Same goes for lambdas with rw signatures:

for @values <-> $even, $odd { $even ÷= 2 } # noo!
for @values ↔ $even, $odd { $even ÷= 2 } # yeaah!

We can also do the same thing with fat arrow:

my %h = 42 => 62 # noo!
my %h = 42 ⇒ 62 # yeaah!

¬ ∧ ∨ ⊻

¬ for logical not
∧ for and
∨ for or
⊻ for xor

√ ∛ ∜

, and . Probably as prefix operators. Some argue that we should only add given that square root is much more common. I think that we should support all of them for consistency.

⁇ ‼ (✓ in rakudo/rakudo#1029)

⁇ ‼ as a non-texas version of ?? !!. Again, it is pretty simple.

Triangular reduce can have its own unicode character too.

.say for [\+] ^10
.say for [◹+] ^10

Other possible candidates:

  • ◿ – it looks more natural but it does not look like its ASCII variant
  • ◺ – does not demonstrate the meaning of triangular reduce (or maybe it does? This definitely looks like reduce)
  • ◥ – probably OK

Questionable things

U+2301 ELECTRIC ARROW ⌁ for the ~~ operator.

By the way, we can't use for anything because it brings a confusion about whether it is an approximation or a smartmatch. In that sense (already supported by Perl 6) and will play well together.

≔ ⩴

as a non-texas version of :=. Pretty obvious.

However, if we are going to add that, then we cannot just leave out ::=, which also has a corresponding unicode character:

⩴ for the ::= operator

The problem is that both are not rendered very nicely by current fonts. is also very wide.

‖ for the || operator

Good, but there is no corresponding non-texas version of &&. So I guess that there is no reason to add that right now.

⩵ ⩶

Even though there are and characters, how are these supposed to look in a fixed-width font?

Although we tend to push unicode adoption, I don't think there's a way to squeeze these things into a width of one character.

In other words: it does not sound like a good idea.

Subscripts

We already have superscripts 4² # Woohoo!, but what about subscripts (*₂)? The choice of unicode characters is pretty much obvious, but what should be the meaning?

There are two options:

  • Subscripts could be allowed in variable names so that you can write my $x₁ = 5
  • Subscripts could act like array subscripts so that you can write @x₁ which will be equivalent to @x[1]

I vote for the second option, but there are some people who strongly want the first one (I just feel like the second one will be more common and more useful).

If we go for the second one, then there are some other interesting possibilities:

  • We can use low asterisk to act like a subscript whatever star: @x⁎₋₁
  • Or we can use as a last index of the array. Like: @xₙ. Perhaps this would make mathematicians happy.

I'd say that in this case we should do both ⁎ and ₙ (because why not).

Another option is to use unicode subscripts as array subscripts if @ sigil is used, but allow subscripts in variable names that have $ sigil. This will probably make all of us happy (but it is going to be so weird…).

Whatever star

The most problematic case was with the code like (* * *)(4, 2). It got better when school-grade math ops were implemented: (* × *)(4, 2), but still, it would be great to have a unicode equivalent to whatever star.

The problem is, there is no obvious character for that.

There are several classes of proposed characters:

  • Star-like symbols: ★ ☆ ٭ ✪ ✶ ⭐ ✰ 🌟 and so on and so forth, unicode has so many of those it's not even funny…
  • Asterisks: ⊛ ⧆ ⁎ ⁑ * ⁂
  • Chars that look like an empty field to fill: 🞅 ◯ ⭕ 🔾 ◌
  • Other: ⍰ ⍣

The problem with stars is that they perfectly represent the “star” part, but not so much the “whatever” part. Circles are just circles, they just don't have enough meaning in my opinion. ⍰ is an APL char, is it even appropriate to use it?

There is one more thing: besides Whatever (*) there is also HyperWhatever(**) which perhaps should also get a unicode symbol. This means that not only we have to find one good single character, it would be better if we had a pair of similar characters (e.g. something like ★ and ☆ but better).

⊞ ⊟ ⊠ ⧆ ⧄ ÷⃞

⊞ – [+]
⊟ – [-]
⊠ – [×] (or something else?)
⧆ – [*]
⧄ – [/]

But of course there are many other operators that people use all the time. To solve this we can use U+20DE COMBINING ENCLOSING SQUARE [Me] (◌⃞):

÷⃞ – [÷]

However, this has a limit of one character per operator, which means that in some cases you will be forced to fall back to Texas […].

can be used as a spaceship operator (<=>). But there are other candidates as well:

U+22DA  LESS-THAN EQUAL TO OR GREATER-THAN ⋚
U+22DB  GREATER-THAN EQUAL TO OR LESS-THAN ⋛
U+1F680 ROCKET                             🚀

The last one is a joke, of course.

∨ and ∧

(suggested by teatime)

∨ for || (unicode character name LOGICAL OR)
∧ for && (unicode character name LOGICAL AND)

-->

⇢
⎯→

say 2‥5

🙼

There is an idea that 🙼 (VERY HEAVY SOLIDUS) can produce a FatRat, as in:

sub infix:<🙼> { FatRat.new: $^a, $^b }

🆕 ideas!

±

± can be used to create ranges. Example:

sub infix:<±> { Range.new: $^a - $^b, $a + $b };
say 5 ± 2      # OUTPUT: «3..7␤»
say 4 ~~ 5 ± 2 # OUTPUT: «True␤»
say 0 ~~ 5 ± 2 # OUTPUT: «False␤»
@AlexDaniel
Copy link
Author

@smls You're absolutely right! I changed the gist accordingly. Thank you for your comment.

That being said, I slightly disagree with your point №3. Sure, there's no need to artificially search for unicode versions of everything, but there are exceptions. The reason why this gist discusses possibilities for Whatever is because:

  1. Some expressions just look ugly otherwise. Example: my $x = * * *. It got better once we got × (my $x = * × *), but even then a unicode version of whatever star can improve readability significantly.
  2. It was requested many times.

Indeed, any replacement for whatever star is not going to fit your criteria, but… we still need it :)

@AlexDaniel
Copy link
Author

@mscha

  1. ± is a good idea, but why junctions? I really think it should return a Range, and that's what I added to the gist now.
  2. ⌊…⌋ and ⌈…⌉ not bad, I'll add it too! Though this one will remain questionable for now :)
  3. and … ouch… what a character. Some people have already complained about because it looks like \… but again, this gist is primarily for gathering all ideas, so I'll add it as well!
  4. and I love this mathy stuff! But again, I don't think it is obvious that we must have this in core.
  5. Infinite sets? What? I have to let that sink for a moment. :)

@AlexDaniel
Copy link
Author

This page is now moved to https://github.com/rakudo/rakudo/wiki/save-me-from-texas

Please feel free to edit it (everyone interested should already have access, I think). Especially feel free to edit it if I forgot to list your idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment