Firacode: Parallelism between ≤, <=, =<, ≥, >=, =>

[wlonk]

Sorry if this is a duplicate, but there's a lack of parallelism that weirds me out:

1. <= to ≤
2. =< to ≤
3. >= to ≥
4. => to ⇒

My suggestion is that 2. should change, perhaps to simply no longer be a ligature?

[j-f1]

Yes! The fact that <= and =< look the same hides syntax errors.

[rocketnik]

Is there a programming language, where less-or-equal is written =< ? This would be a good reason for the font to show this character. I would assume, that for most languages the compiler will find the syntax error when using =< instead of <=, but I might be wrong. I could imagine, that a custom operator =< is defined in a language for that the compiler does not type check the expression - or it even type checks, because it has the same type signature as <= ). Is it more common to define a custom operator =< for which you would want to display a different symbol than ⩽ or is it more common that programming languages have =< already defined (e.g. as their less-or-equal operator)?

[j-f1]

I think it’s far more common to have --var=<value> in CLI docs.

[aschrab]

The =< case was also mentioned in #305.

[OskarSigvardsson]

There is at least one programming language where =< is "less than or equal", which is Prolog. I think the CLI docs issue is a bigger issue though, and Prolog programmers will just have to live with not having a ligature there.

[Crissov]

Huh, I thought the even more weird thing was that => becomes an arrow, but <= does not.

[wopian]

@Crissov => is an arrow function in ES6 (and some others). The reverse is less than or equal to in pretty much every language that uses <=

[tonsky]

Huh, I thought the even more weird thing was that => becomes an arrow, but <= does not.

Fira Code was always about practice, not symmetry. <= almost always mean less or equal, => almost always means an arrow. You should complain to people who invented those syntaxes, not me

[vladdu]

FWIW, in Erlang, =< is the comparison operator, while <= is a backwards pointing arrow...

I'm not sure if I should comment on all related issues, maybe just one should be kept open?

[Crissov]

In conclusion, many languages pair <= and >= as comparison operators, while others choose =< and >= for this purpose so they cannot be confused with (assignment) arrows <= and => which they may also be using. The only safe assumption is that >= and => can be rendered as ≥ and ⇒, respectively. =< should always be displayed as ≤ if it was replaced, but this can lead to confusion. <= is the only sequence that has two different interpretations depending on the language, namely ≤ and ⇐.

Default:

• <=
• =<
• >= ↦ ≥
• => ↦ ⇒

Set 1:

• <= ↦ ≤
• =<
• >= ↦ ≥
• => ↦ ⇒

Set 2:

• <= ↦ ⇐
• =< ↦ ≤
• >= ↦ ≥
• => ↦ ⇒

[Crissov]

So, v1.205+ implements what I called Set 1 above as the default, i.e. it follows the original suggestion by @wlonk in this issue.

[jevogel]

Would it be possible to have separate sets released so we can choose which we prefer to use?

I mainly work with VHDL and in my code <= is used far more often as a backwards arrow than less-than-or-equal (although it can be either depending on context), so I'd prefer to be able to install the font with Set 2.

[tonsky]

@jevogel eventually, it’s the direction I want to go. It requires lots of work though to set up correctly, so don’t expect it happening very soon

[jevogel]

Understood. Thanks for your response.