Firacode: Ligature requests: .< and >. and .~ and !.

Created on 12 Dec 2017  Â·  7Comments  Â·  Source: tonsky/FiraCode

In MetaOCaml, .< e >. is used to encode the quasi-quoting of expression e, whereas .~e is to unquote / escape. These are beautifully encoded in the paper and documentation, but look horrific in actual source-code. Compare:

screen shot 2017-12-12 at 12 55 43

vs.

screen shot 2017-12-12 at 12 56 05

Typographic ligatures could go a long way towards improving the usability of MetaOCaml; I'd really love to see these supported by Fira Code. (=

(Also see #317 and, especially, #380.)

Most helpful comment

What exactly does the paper do with .<, >., and .~? I’m having a hard time finding them in the text.

All 7 comments

What exactly does the paper do with .<, >., and .~? I’m having a hard time finding them in the text.

Metaprogramming, basically.

I’m on my phone, but they’re very similar to Lisp’s quasi-quoting — the purpose overall being runtime code-generation, and specifically (compile-time) typed code-generation.

(I’m speaking a little out of my ass, let’s be clear — I’m new to all this, too!)

Oh and in the picture paper, the Unicode tall-angle-bracket has the meaning that is encoded in dot-lessthan in ASCII, I just belatedly realized that may be what you’re asking 🤣

Showing them the way they are in the paper doesn’t work when the symbols are used in other languages. They don’t make it clear what the component symbols are, and they make ligatures of things that are logically separate. For example:

if (x>.85) {        // Comparison against 0.85
    obj.~Class;     // Explicitly call destructor in C++
} else if (3.<x) {  // Compare against 3.0
    // ...
}

And in something that uses ! for shell escapes, !. can start !./my_program.

See my comment on #380 — I wasn’t suggesting they be converted to another glyph (other software already does that), but that they be beautified and kerned a lá the other Fira ligatures!

I’d want to be careful even there; in the examples I gave it would be incorrect to kern them as though they were a single token as they are in OCaml. Maybe it would work if you required whitespace (or another of these ligatures) to be on the other side of the .?

That makes a lot of sense to me — it'd be really messy to kern 0.<=1 or similar, in languages that denote floats that way.

:+1:!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tomByrer picture tomByrer  Â·  4Comments

pamu picture pamu  Â·  3Comments

ulope picture ulope  Â·  4Comments

Jhonyrod picture Jhonyrod  Â·  4Comments

mlajtos picture mlajtos  Â·  4Comments