Friday Finking: Beyond implementing Unicode

[DL Neil]

Unicode has given us access to a wealth of mathematical and other 
symbols. Hardware and soft-/firm-ware flexibility enable us to move 
beyond and develop new 'standards'. Do we have opportunities to make 
computer programming more math-familiar and/or more 
logically-expressive, and thus easier to learn and practice? Could we 
develop Python to take advantage of these opportunities?

TLDR;? Skip to the last paragraphs/block...


Back in the ?good, old days, small eight-bit computers advanced beyond 
many of their predecessors, because we could begin to encode characters 
and "string" them together - as well as computing with numbers.

Initially, we used 7-bit ASCII code (on smaller machines - whereas IBM 
mainframes used EBCDIC, etc). ASCII gave us both upper- and lower-case 
letters, digits, special characters, and control codes. Later this was 
extended to 8-bits as "Code Page 1252", whereby MSFT added more special 
characters, superscripts, fractions, currency symbols, and many ordinary 
and combinatorial letters used in other "Romance languages" (European).

Latterly, we have implemented Unicode, which seeks to include all of the 
world's scripts and languages and may employ multiple bytes per 
'character'. (simplification)

A massive effort went into Python (well done PyDevs!), and the adoption 
of Unicode in-particular, made Python 3 a less-than seamless upgrade 
from Python 2. However, 'standing upon the shoulders of giants', we can 
now take advantage of Unicode both as an encoding for data files, and 
within the code of our own Python applications. We don't often see 
examples of the latter, eg

 >>> π = 3.14159
 >>> r = 1
 >>> circumference = 2 * π * r
 >>> print( circumference )
6.28318

 >>> Empfänger = "dn"                # Addressee/recipient
 >>> Straßenname = "Lansstraße"      # Street name
 >>> Immobilien_Hausnummer = "42"    # Building/house number

(whilst the above is valid German, I have 'cheated' in order to add 
suitable characters - for the purposes of illustration to 
EN-monolinguals - apologies for any upset to your sense of "ordnung" - 
please consider the meaning of "42" to restore yourself...)


However, we are still shackled to an history where an asterisk (*) is 
used as the multiplication symbol, because "x" was an ASCII letter. 
Similarly, we have the ** for an exponential operator, because we didn't 
have superscripts (per algebraic expression). Worse, we made "=" mean: 
'use the identifier to the left to represent the right-hand-side 
value-result', ie "Let" or "Set" - this despite left-to-right expression 
making it more logical to say: 'transfer this (left-side) value to the 
part on the right', ie 'give all of the chocolate cake to me', as well 
as 'robbing' us of the symbol's usual meaning of "equality" (in Python 
that had to become the "==" symbol). Don't let me get started on "!" 
(exclamation/surprise!) meaning "not"!


There is/was a language called "APL" (and yes the acronym means "A 
Programming Language", and yes it started the craze, through "B" (and 
BCPL), and yes, that brought us "C" - which you are more likely to have 
heard about - and yes then there were DataSci folk, presumably more 
numerate than literate, who thought the next letter to be "R". So, sad!?).

The point of mentioning APL? It allowed the likes of:

AREA←PI×RADIUS⋆2

APL was hopelessly keyboard-unfriendly, requiring multiple key-presses 
or 'over-typing' to produce those arithmetic-operator symbols - 
remember, much of this was on mainframe 3270-style terminals, although 
later PC-implementations have existed (I can't comment on how 'active' 
any community might be). The over-typing was necessary to encode/produce 
the APL symbols which don't exist on a standard typewriter keyboard. Ugh!

I'm glad to have limited my APL-exposure to only reading about it during 
a 'Programming Languages' topic! (If you are 'into' functional 
programming you may like to explore further)


Turning now to "hardware" and the subtle 'limitations' it imposes upon us.

PC-users (see also Apple, and glass-keyboard users) have become wedded 
to the 'standard' 101~105-key "QWERTY"/"AZERTY"/etc keyboards (again, 
restricting myself to European languages - with due apologies). Yet, 
there exists a variety of ways to implement the 'standard', as well as a 
range of other keyboard layouts. Plus we have folk experimenting with 
SBCs, eg Raspberry Pi; learning how to interpret low-level hardware, ie 
key-presses and keyboard "arrays", and developing/innovating all-manner 
of special interfaces and other tools.


Back to Python, or is it 'forward to Python':

In the same way that we often add a "numeric key-pad" to the standard 
'typing' alphanumeric keyboard, could we add another key-pad or row of 
keys? Might such give us the opportunity to start employing other, and 
more logical symbols for programming, eg directional arrows, a modifier 
key to enable subscripts and another for superscripts, Greek/Math 
symbols to release us from the approximations/alternatives such as 
asterisk-means-multiply, and so-on...?

Could we then also 'update' Python, to accept the wider range of symbols 
instead/in-addition to those currently in-use?

Would such even constitute 'a good idea'?


Web.Refs on hardware:
https://imgur.com/a/AalpV1r
https://github.com/mattdibi/redox-keyboard
https://github.com/BenRoe/awesome-mechanical-keyboard
https://github.com/help-14/mechanical-keyboard
https://github.com/makerdiary/python-keyboard?mc_cid=fc3464732f&mc_eid=cd74eeaf09

Web.Refs on the rest:
https://www.ascii-code.com/
https://en.wikipedia.org/wiki/APL_syntax_and_symbols
https://en.wikipedia.org/wiki/Digital_encoding_of_APL_symbols
https://en.wikipedia.org/wiki/IBM_PC_keyboard
-- 
Regards,
=dn