The Hegemony Of `==` Must End; Welcome The `⩵` Upstart

Offtopic
21

This is basically just font ligatures, and is a feature of the font itself, and doesn’t need to have anything to do with the programming language.

See e.g. Hasklig, Fira Code and JuliaMono.

So this is already available for Julia, and any other language, for that matter.

3 Likes
22

because your right pinky never presses =.
Instead, you type \ie[tab] and ⩵ is inserted.

1 Like
23

This response is terrible.

First, you cannot force other people to like what you like. Even if this new syntax was accepted into Julia source code, most library maintainers would still not accept PRs with unicode (i.e. non-ASCII) characters.

Second, if you are the only one in the world who uses a different syntax, that DOES NOT make you creepy. Today is Pride Day, the best day to remember that being different is not creepy, not weird nor sinful. It is also the day to remember that people have different tastes and opinions. Diversity is a good thing.

In short, if you want to use a different syntax, use it. The option is already on the table. If other people adopt it, that’s great, otherwise, that’s okay, too.

11 Likes
24

Sure, but suggestion was to treat the ligature as alias: ⩵ and ==, which is not currently the case (I’ll edit my post to clarify). It’s great that the ligature(s) are available in multiple fonts, so why not build them in? (As others have noted, this could/should be implemented in a package, which would make it convenient to test out.)

25

I like this idea. It meets the requirement.

The documentation for custom keybindings

The documentation says to * Users should refer to LineEdit.jl to discover the available actions on key input.*

This file can be found in julia/share/stdlib/v1.6/REPL/src

LineEdit.jl is a 2563 line program written by someone obviously very skilled in writing a character interface.

The “available actions” appear to start at line 238. “:edit_insert” looks promising. Search for “edit_insert” and you find the function edit_insert() at line 736.

At that point, function edit_insert() is incomprehensible to me.

So, let’s try guessing (if you consider this to be a bad method, you would be correct):

This does not work:

import REPL
import REPL.LineEdit

const mykeys = Dict{Any,Any}(
    # \ie[tab] to ==
    "\\ie" => (s,o...)->(LineEdit.edit_insert, s, "==") 
)

function customize_keys(repl)
    repl.interface = REPL.setup_interface(repl; extra_repl_keymap = mykeys)
end

atreplinit(customize_keys)

In fact, executing the above in your startup.jl will prevent you from typing the letter “e”.
You can’t type exit() to get out.

It took me about two hours to come up with that guess (it is in fact guess version 4, the first three were worse).

26

If after a while you get a bunch of users, revive this topic: you will be in a much better position to argue for it.

That’s just erecting a marketing barrier to the proposal. Say I create a “package” (consisting of one line of code). Users may love it, but if they don’t know about it, they can’t benefit from it. Package popularly then depends on how well it is marketed to the user base, not on how much user benefit comes from it.

Package popularity is also not always indicative of a change you would want to make. Say I marketed the brilliant TwoBasedIndexing package and got 10,000 users to implement and use it. Would that convince you to finally implement two-based indexing into Julia and replace “obsolete one-based indexing to proper two-based indexing”?

27

But your brain does :wink:

28

I think we are talking past each other. The programming language has nothing to do with this, and you don’t have to ‘treat’ anything as an alias, because it’s just one ‘thing’.

When a font supports ligatures it means that it just displays a character combination in a certain way, without changing the underlying representation. There’s no need for a Julia package, it’s handled entirely by the font itself, plus the editor, which needs to support it, and this is not the case for the REPL – is that what you are referring to?

I mean, this already exists and works for VS Code and Sublime Text, at least, probably more. The fonts just need to introduce a ligature for ==. Julia doesn’t need to do anything at all.

Update: It seems that Fira Code, does already, but not JuliaMono. I’m not sure if this is distinctive enough, though:
image

1 Like
29

Great.

I would suggest opening a separate topic on the specific question of how to implement a new tab-completion for your editor/repl.

30 
julia> isequal(NaN, NaN*5)
true

julia> NaN==NaN*5
false

Let’s try it with missing

julia> isequal(missing,missing)
true

julia> missing==missing
missing

That last one is a little surprising (although consistent with documentation)

31

Ah, thanks for the explanation. I was in Monaco font in terminal REPL. I’ve installed Fira Code (and “Use ligatures” in iTerm2) and can verify that it does do the ligature properly, and still treats (e.g. copies) it as two equals chars ==.

The ligature is a neat editor feature, but I think it is still different from REPL. With ligatures turned off, I can type \ge to get ≥ which I believe to be an alias for >=, that also looks distinctly different from the Fira Code ligature. For consistency, I’d be in favor of REPL treating \Equal as alias for ==. The issue isn’t the input, it’s the treatment.

Not that anybody cares, but Mathematica does it a slightly different way, because you type two characters -> and copy just one →.

32

but people don’t write Mathematica over ssh on vi, you can do whatever you want, Julia has support for you:

julia> const ⩵ = ==

or you can open a PR to add this alias, or just use a font with ligatures. It’s all up to you, but please don’t open two thousands PR later to add this and change every == to ⩵ across all julia rpeo (semi-jokingly

2 Likes
33

About ligatures and Julia Mono, I recently opened an “issue” about it, if some of you are interested.

1 Like
34

Yes, ≥ is a unicode character which is separate from >=, while the font ligatures are just a display effect, and keeps the underlying characters unchanged, so when someone else looks at my code, they cannot tell if I have used ligatures or not.

Whether or not ≥ is an alias for >= is entirely up to Julia, while font ligatures are completely not.

2 Likes
35

I think that ⩵ should be an alias for ==, not for the reasons mentioned above, but simply because it would discourage people from making it an alias for something else.

7 Likes
36

If it really becomes a Big Deal, please allow BOTH syntaxes to be ==. And no one will have to change their code.

4 Likes
37

You can find the completion engine in stdlib/REPL/src/REPLCompletions.jl. Currently it assumes that completions starting with a \ character are either LaTeX or (if starting with \:) emojis. So a proper implementation would require a refactoring, but for a quick test you can add a “LaTeX” completion:

Base.REPL_MODULE_REF[].REPLCompletions.latex_symbols["\\ie"] = "=="
2 Likes
38 
function ⩵(args...)
    @warn "you think you need this, but you don't, really"
    exit(666)
end

could also work for that purpose.

15 Likes
39

Some say this would be a breaking change since some modules might already be using ⩵ for other purposes, but couldn’t this problem be solved (and thus have a whole consistent group of single-character Unicode operators) by temporarily adding a warning when this symbol is currently used not as an alias for ==? Same for ⩶, while we’re at it!

40

Objection: It’s just one of many common errors
@oheil replied:
There are a lot of common errors. E.g. forgetting ; at the end of a line, forgetting a closing " at the end of a string, using ' instead of " for strings, just to name a few which come to mind for this and other languages.

Response: Not quite the same.

That’s not really the argument I would make. I think it’s exactly the same – and fixing common mistakes like thesse is a good idea. Julia has already fixed the problem of ; by assuming a new line of code is, well, a new line. This despite adding semicolons not being that difficult; sure, but why make it harder? (' vs " has a useful role – a single character is different from a string, and in a typed language like Julia this can be a useful distinction from time to time. On the other hand, there’s nothing useful that =? or ≟ are doing at the moment – there’s no cost to aliasing them to isequal, and they’d clearly be popular among at least a handful of programmers.)