
Mathematical Notation in Emacs - signa11
https://ekaschalk.github.io/post/prettify-mode/
======
reikonomusha
Is the example they show intentionally hyperbolic? Most of the notation is
used incorrectly.

* "returns" being |--> is awkward and out-of-line with the meaning of that symbol. |--> is usually read as a transitive verb "maps to".

* Using the calligraphic F for "def" is extremely weird and unhelpful.

* Having None be the empty set symbol, which is not set(), is strange.

* Blackboard bold F for False is weird, usually that means a finite field.

* Blackboard bold S for string?

* The dissonance between what the blackboard bold characters mean is jarring. Sometimes it's a type, somethings it's a particular object.

* Whatever the notation is for list and dict types (fraktur) is extremely non-standard and overly frilly.

The Greek/AND/OR/comparisons/not-equal/etc stuff is pretty OK. It's actually
truly in-line with their meaning in math.

I am only saying this because the author points out at the end in a serious
fashion that it's a useful thing to do for readability.

Don't be fooled. Just because you can make your editor look kinda-sorta like
math, doesn't mean it actually is math.

~~~
dzamo_norton
The use of \mathbb{R} for floats acts to obscure things for me I'm afraid. It
loads up dusty old stuff in my brain about the reals that is not true of
floats from the slow tape archive storage in my skull, and _doesn't_ load up
stuff in my brain about floats like, say, where the first integer gap
occurs[1]. A side note is that \mathbb{Q} would be a closer match to float.

[1] [http://stackoverflow.com/questions/3793838/which-is-the-
firs...](http://stackoverflow.com/questions/3793838/which-is-the-first-
integer-that-an-ieee-754-float-is-incapable-of-representing-e)

~~~
qrian
I think we should view them as what we are trying to represent, not what they
really are. Besides, with the same logic int32 or int64 isn't really an
integer in a sense that it can't represent 2^64.

~~~
OJFord
It's still 'an integer'^, it's just that the set {i | i \in int64} is a
_proper_ subset of \mathbb{Z}; so using the latter to denote the former is
inappropriate.

^i.e. for all i \in int64, i \in \mathbb{Z}.

------
nothrabannosir
I think it looks great. Elegant and concise. Programming was never
mathematics, anyway. That hasn't stopped the butchering of notation ("=" for
assignment, functions with side effects), why is everyone suddenly a
mathematical purist, now?

It's a fine theme.

~~~
fsloth
Nothing wrong as personal shorthand - but the multiplier effect of
understandable notation should not be underestimated.

Non-conventional notation strips away the benefit of shorthand notation in
collaborative environment - nobody actually can tell what the meaning is just
by looking at it without learning it first. If applied generally to software
development, using an exotic notation _just because it looks nice_ is risky
and of questionable value. New notation is always a huge burden and should be
taken into use only if there is some actual benefit other than aesthetics.

~~~
apetresc
Unless I'm missing something, this is just an emacs style, equivalent to a
syntax coloring theme. Collaborative environments have nothing to do with it -
it will be checked into SCM in the normal way, and the guy running this emacs
plugin is the only person who will see the symbols.

------
torrent-of-ions
This looks nice but, as others have pointed out, it's mostly wrong to a
mathematician. Yes, programming languages are already wrong (assignment should
be <-, equality should be =, functions should be called subroutines etc.), but
at least they're mostly all wrong in the same ways.

The main problem I have with it is I want to edit the _text_ , not some pretty
rendering. I use some display rendering in emacs, in org-mode to be specific,
but none at all in programming modes, even in Lisp where one doesn't need to
edit S-expressions directly. I guess I've been bitten by software where the
display doesn't equal the underlying data too many times.

------
mrighele
Note that if you use a variable width font (and so you don't care much if >=
has different width than ≥ ) you can simply use font-lock-add-keywords and map
what you need. For example in JS you could use

    
    
        (font-lock-add-keywords 'js2-mode '(
        				    ("=>" (0 `(face nil display "")))
        				    (">=" (0 `(face nil display "≥")))
        				    ("<=" (0 `(face nil display "≤")))))
    

EDIT: It seems that HW doesn't really like U+27A1 ... :-)

~~~
anamoulous
Are you coding javascript in a variable width font?

~~~
mrighele
As strange as it may sound, yes. It took some time to get used to it, but now
I find the code easier to read. There are a number instances where the missing
vertical alignment is a drawback, for example ASCII art, boxed comments or
comments on the right of the code, but since I don't make use of them it is
not an issue for me.

~~~
metaobject
I'm not sure I could ever write code in a non-fixed-width font. Maybe if I
wrote every line perfectly and never had to navigate back a few lines to make
adjustments. But then again, I spend a non-trivial amount of time lining
code/variables up and making things just right before moving on that a
variable-width font would probabky drive my OCD (Obsessive Code Disorder)
levels up to 11.

I don't even want to see what happens when you mark a region and call M-x
align in a variable width font.

------
nerdponx
Better idea: since Python accepts UTF-8 input, let me actually enter the Greek
letter lambda in place of the word "lambda". On a Mac it's close to trivially
easy to switch between Greek and English keyboard layouts.

------
taeric
I find this an interesting diversion back down the path of cweb. Specifically
to introduce some more notations for things such as Null, and the boolean
operations.

