stz the mac keyword

This is the kind of decision that can upset an ecosystem. Anyone who has owned and programmed on a mac for a while knows that we can write ≤ ≥ and ≠ super easily.

It makes it oh so tempting to use these unicode symbols in the language because they are the correct symbols to use. The language must already support unicode (utf-8 in my experimental parser) so why not go that extra step?

Well.. because of Linux and Windows. Those environments don't give easy access to these keys. As such any fun unicode character used in the language has to either not be used in the language or backed up with a non-unicode variant.

Let's make a list:

less-than-or-equal      ≤   <=
greater-than-or-equal   ≥   >=
not equal               ≠   !=
not                     ¬   !
sort of equal           ≈
pi                      π   pi
divide                  ÷   /
multiply                ·   *
nothing                 ø   nil or null
infinity                ∞   infinity
dot-product             •   dot-product
ohm                     Ω   ohm
either-side-range       ≠
extra-quote             ‘’
extra-double-quote      “”
extra-bracket           ‹›
extra-double-bracket    «»
ellipsis                …   ...
micro                   µ   micro
derivative              ∂
delta                   ∆
sum-of                  ∑
degree                  °   deg

Not all of these are comfortable to type. But some of them are. I think my desire is to pick the most commonly used ones and have them be aliases for the C standard names.

It would be nice not to have a bunch of ! everywhere (even though we did just free up ! for use again in the previous post).

And editors like zed.dev will make a ≤ out of <= for you which is kinda neat. But also trying to patch over the problem of not having enough keys on our keyboards.

Also, these are just the ones I know how to type on my mac keyboard without too much difficulty. There's a heap more useful symbols in unicode in general - should I ask that everyone remap their keyboard to use stz. No of course not that'd be very silly.

There's also a bunch of currency symbols if I felt like including currency as a concept in the language. I don't think I do. The value of a currency is in isolation and cannot be converted to another currency without resolving a LOT of rules. That is not a programming language domain but a financial development domain.

There's no real change required here except I updated all my test files. I was using ¬ to delineate between the stz code and the expected parse tree. I've swapped that to ∆ delta now instead.