# Syntax: Escape hatch for unicode haters

**URL:** <https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363>\
**Category:** Internals & Design\
**Tags:** syntax, unicode\
**Created:** [January 4, 2024, 11:55pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363 "2024-01-04T23:55:47Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [January 8, 2024, 11:42pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/41 "2024-01-08T23:42:58Z")

</div>

> [@DNF](#):
>
> But the repeated criticism of those who find it pleasant and useful is getting increasingly annoying.

Sorry you feel that way. But I think my raining on the parade may provide a useful viewpoint to those newbies who would otherwise be exposed only to uncritical cheerleaders clamoring for more unicode in the source code. (Note: I have no objections to it in comments and documentation. Knock yourselves out writing all those umlauts and checks and weird dots and wiggly lines. I speak more or less seven languages and I can see the use case for those little quirks. But in source: the fewer possibilities for confusion, the better. If a programmer spends just five minutes a day being confused by a symbol in code, the costs will add up quickly.)

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [January 8, 2024, 11:52pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/42 "2024-01-08T23:52:39Z")

</div>

For my part, I find that a few well-placed Greek letters can significantly clean up a piece of code and make it both easier to read and understand.

If someone is confused by a `θ` in my code, I sincerely wonder which parts of it they do understand.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [January 9, 2024, 12:02am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/43 "2024-01-09T00:02:17Z")

</div>

I think you know well that that is not what I am concerned about.

These are all “rhos”, yet they are all different (distinct) characters, which could potentially have all different meaning.  
 ![image](https://global.discourse-cdn.com/julialang/original/3X/e/1/e193cf13104c8588983c6836aea1d9595dbc4e93.png)  
 ![image](https://global.discourse-cdn.com/julialang/original/3X/1/5/15144203e769a53ec292f83e88a70c5c1887b490.png)  
Does it still seem like a good idea?

---

<div class="post-metadata">

**Author:** ![jkopper](https://avatars.discourse-cdn.com/v4/letter/j/958977/32.png) [@jkopper](https://discourse.julialang.org/u/jkopper)\
**Post date:** [January 9, 2024, 12:30am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/44 "2024-01-09T00:30:03Z")

</div>

> [@DNF](#):
>
> As a non-ascii person, by name and language, I find the clinging to an outdated character set quite off-putting. The consequences of this attitude is a source of annoyance and uncertainty every time I book an international plane ticket. Anything that can work to spread the acceptance and use of unicode is great in my book.

I think it’s disingenuous and underhanded to pretend that this is remotely related to what I’m talking about.

I am not arguing against unicode _per se_. I am describing how its use in Julia is a significant pain point for me and people who program like me.

---

<div class="post-metadata">

**Author:** ![Dan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dan/32/42581_2.png) [@Dan](https://discourse.julialang.org/u/Dan)\
**Post date:** [January 9, 2024, 1:07am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/45 "2024-01-09T01:07:11Z")

</div>

A solution could be essentially, a “beautifier” option. The beautifier/formatter would replace unicode with equivalents (such as `lvar"rho"` suggestion above), but perhaps integrated into main julialang. Additionally, the REPL should have a mode which automatically replaces unicodes with such equivalents also. In this way, pasting into REPL with this REPL option activated will result in non-unicode characters.

Perhaps a more elaborate solution is possible.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [January 9, 2024, 1:12am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/46 "2024-01-09T01:12:52Z")

</div>

> [@stevengj](#):
>
> I don’t recall any feature of the base language or standard libraries that _requires_ non-ASCII symbols

[JAX vs Julia (vs PyTorch) · Patrick Kidger](https://kidger.site/thoughts/jax-vs-julia/) says

> Many Julia APIs look like `Optimiser(η=...)` rather than `Optimiser(learning_rate=...)`. This is a pretty unreadable convention.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [January 9, 2024, 1:20am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/47 "2024-01-09T01:20:23Z")

</div>

This thread is getting dangerously close to name-calling. It’s hardly productive to have a shouting match between unicode haters and unicode enthusiasts. It’s not like anybody is going to convince the other.

Julia’s unicode support is a fact of life. If you don’t like unicode, don’t use it in your code base. As soon as you want to contribute to other people’s code, you’ll have to contend with their use of unicode. If I were to submit patches to @PetrKryslUCSD’s code, I’d make sure they’re in ASCII. Conversely, I wouldn’t accept contributions that don’t match the extensive use of unicode my projects.

In practice, there seems to be a pretty strong consensus in the community:

- Don’t force unicode for public APIs. So no unicode in types / function names, and no unicode keyword arguments without ASCII aliases
- Limit unicode to where it relates to existing mathematical notation. Non-scientific code doesn’t need unicode identifiers.

Seems quite sensible to me, and at least in my opinion, the judicious use of unicode greatly enhances the readability of scientific code. But everyone is going to follow their own philosophy, and things will land where they’ll land.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [January 9, 2024, 1:33am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/48 "2024-01-09T01:33:55Z")

</div>

> [@jar1](#):
>
> [JAX vs Julia (vs PyTorch) · Patrick Kidger](https://kidger.site/thoughts/jax-vs-julia/) says
> 
> > Many Julia APIs look like `Optimiser(η=...)` rather than `Optimiser(learning_rate=...)`. This is a pretty unreadable convention.

I’m pretty sure that Patrick Kidger is just plain wrong in that assertion. I’m not a Flux user, but as far as I can tell, Flux (or any other common library) does not have an API that includes `Optimiser(η=...)`. Their documentation isn’t great: At first glance, they make it _look_ like you can call their functions like that. But in fact, these are _positional_ parameters, so you call them as `Optimizer(learning_rate)` or `Optimizer(η)`, or whatever you want. The field names and required keyword arguments all seem to be ASCII.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 9, 2024, 1:40am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/49 "2024-01-09T01:40:53Z")

</div>

That’s neither Base Julia nor a standard library. One of the most prominent package style guides, [SciMLStyle](https://docs.sciml.ai/SciMLStyle/stable/), says this:

> - Unicode is fine within code where it increases legibility, but in no case should Unicode be used in public APIs. This is to allow support for terminals which cannot use Unicode: if a keyword argument must be η, then it can be exclusionary to uses on clusters which do not support Unicode inputs.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 12, 2024, 3:22pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/50 "2024-01-12T15:22:46Z")

</div>

9 posts were split to a new topic: [Warning against Unicode confusables](https://discourse.julialang.org/t/warning-against-unicode-confusables/108734)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 9, 2024, 6:37am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/52 "2024-01-09T06:37:10Z")

</div>

> [@jkopper](#):
>
> If I can’t ssh into a terminal and edit code with whatever editor happens to be installed, then your language isn’t useful to me.

With [tramp in Emacs](https://www.gnu.org/software/tramp/), I can edit any file on a server I have SSH access to using the editor on my local machine.

I don’t think that non-ASCII chars should be used excessively in generic APIs, but I am relatively unsympathetic to claims of how Unicode makes life hard for people when the tooling to deal with it has been around for decades. Eg in this case, tramp has been bundled with Emacs since 21.1, which was released around 2001. (Again, I think VS Code has something similar, but didn’t explore in detail).

But the bottom line is: if Julia is not useful to you, then just don’t use it. No one is forcing you to.

> [@jkopper](#):
>
> Counterpoint: Perhaps many people are sufficiently annoyed that they’re opting out of using Julia altogether.

I don’t think this is true, for the following reason: Julia is free software. If there were masses of people who would use it if it wasn’t for Unicode, they could just easily fork it and strip all traces of Unicode from it (and backport all future changes from Base and the compiler, as those hardly use any Unicode).

This is not happening, so maybe there are not many people who are serious about hating Unicode. Now of course they will kvetch about it any time they have an opportunity, but talk is cheap.

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [January 9, 2024, 1:53pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/53 "2024-01-09T13:53:18Z")

</div>

This is a case where Julia has built-in functions to help out. Someone posted this already, but its worth reiterating

```julia
help?>α
"α" can be typed by \alpha<tab>

```

so the “which theta is it mystery?” is readily solveable by copy/pasting into the REPL. I will say though that I always forget this, so a PR to the top of Julia manual’s [Unicode Input](https://docs.julialang.org/en/v1/manual/unicode-input/) section about working with unicode characters in source code maybe would be good. It could include looking up characters using `help?>`, how to use `codeunits`, and advice on when to use/not use unicode (such as avoiding unicode keywords in function APIs).

Side note: the Julia VS Code extension does give confusion warnings, so for my Planck Law’s example the characters are highlighted and hovering on them tells me that `ν` can be confused with `v`, and even gives the code points. So there is that.

In the larger context, I get that people are annoyed by too much unicode. I rather dislike it myself, so I use unicode sparingly and only when it makes the code more readable/understandable (e.g. in well-known physics equations).

But the other argument about not being able to type/display unicode seems to be a [red herring](https://en.wikipedia.org/wiki/Red_herring). What I see so far is: _a hypothetical user is doing a task of some kind and the only text editor they have cannot display a single unicode character_. Since no one has posted a real, lived example of this happening, my assumption has to be that it really doesn’t happen **in practice**. If it did, then someone would surely post their workflow breaking because of it, right?

Nearly all unicode characters I come across are mathematical symobls, so sure, VS Code with the [JuliaMono](https://juliamono.netlify.app/) font doesn’t display `\:spagetti:` properly, but is that used in code **in practice**? “In practice” is highly relevant because it is really hard to design a solution in search of a problem. Again, I do not dismiss that it can be annoying to deal with unicode since I have experienced that myself. But “annoying” is very different from “it literally prevents me from coding”. And the latter requires examples to test against.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 9, 2024, 1:59pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/54 "2024-01-09T13:59:19Z")

</div>

> [@mihalybaci](#):
>
> VS Code with the [JuliaMono](https://juliamono.netlify.app/) font doesn’t display `\:spagetti:` properly

Fear not, [Iosevka](https://github.com/be5invis/Iosevka) does 😉

Along with 🚴‍♂️ (`\:bicyclist:`). Which makes sense on so many levels: if you eat a lot of spaghetti you need to exercise.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 9, 2024, 2:38pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/56 "2024-01-09T14:38:05Z")

</div>

Hey everyone, we’ve [had this rodeo before](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897). Unicode isn’t going anywhere, neither in the world at large nor [in Julia](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872) nor in any other modern language.

The topic at hand here is if adding an ASCII-equivalent syntax to enter unicode identifiers (as is possible in Javascript) would actually help alleviate any difficulties and if it’d be a good idea.

Let’s not just argue with eachother here for the sake of arguing, please.

---

<div class="post-metadata">

**Author:** ![mikmoore](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikmoore/32/31109_2.png) [@mikmoore](https://discourse.julialang.org/u/mikmoore)\
**Post date:** [January 9, 2024, 5:04pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/58 "2024-01-09T17:04:45Z")

</div>

> [@DNF](#):
>
> never have I been _forced_ to use it. What APIs are forcing this on the user?

I only have one example and it’s only partial, but notice that n-ary function composition is only available via `∘` (`\circ`):

```julia-repl
julia> methods(ComposedFunction)
# 1 method for type constructor:
 [1] ComposedFunction(outer, inner)
     @ operators.jl:1038

julia> methods(∘)
# 3 methods for generic function "∘" from Base:
 [1] ∘(f, g)
     @ operators.jl:1053
 [2] ∘(f, g, h...)
     @ operators.jl:1054
 [3] ∘(f)
     @ operators.jl:1052

```

Maybe I’ll get around to adding n-ary versions of `ComposedFunction` one of these days. If someone else gets to it before me, even better.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 9, 2024, 5:18pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/59 "2024-01-09T17:18:11Z")

</div>

> [@mikmoore](#):
>
> but notice that n-ary function composition is only available via `∘` (`\circ`):

```julia
julia> sin ∘ cos ∘ tan === ComposedFunction(ComposedFunction(sin, cos), tan)
true

julia> sin ∘ cos ∘ tan === foldl(ComposedFunction, (sin, cos, tan))
true

```

---

<div class="post-metadata">

**Author:** ![mikmoore](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikmoore/32/31109_2.png) [@mikmoore](https://discourse.julialang.org/u/mikmoore)\
**Post date:** [January 9, 2024, 5:27pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/60 "2024-01-09T17:27:46Z")

</div>

Of course. But why is `∘` privileged to not require a fold? My point is that there are many Unicode definitions like `const ⊻ = xor` but `∘` does not follow this pattern.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 9, 2024, 5:41pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/61 "2024-01-09T17:41:43Z")

</div>

> [@mikmoore](#):
>
> But why is `∘` privileged to not require a fold?

Probably because the need for it never occured to anyone: `ComposedFunction` was viewed as the lower-level building block and no one saw a need for more high-level constructor methods, since in the real world almost nobody calls it directly. Indeed, if you use JuliaHub to search the thousands of Julia packages for [usage of `ComposedFunction`](https://juliahub.com/ui/Search?q=ComposedFunction&type=symbols), people are mostly using it for dispatch. There only seem to be ~~two~~ three instances of anyone calling it directly: [one line in InverseFunctions.jl](https://github.com/JuliaMath/InverseFunctions.jl/blob/v0.1.12/src/inverse.jl#L87), [one in Bijectors.jl](https://github.com/TuringLang/Bijectors.jl/blob/2402be2be1d572f1dabd02701c09369b68939e07/src/interface.jl#L21), and [one in FunctionChains.jl](https://github.com/oschulz/FunctionChains.jl/blob/042581cf3dd58c5b38df81b0dd2f472c796e6072/src/function_chain.jl#L80), which call 2-arg and 1-arg versions respectively — in each case, this occurs in methods that are overloaded for `::ComposedFunction` arguments, where they maybe wanted to call the low-level constructor explicitly to clarify that the result is the same as the argument type. (This doesn’t exactly speak to a burning desire for `∘` synonyms, either — [`∘` is used directly much more often](https://juliahub.com/ui/Search?q=%E2%88%98&type=symbols) than `ComposedFunction`.)

> [@mikmoore](#):
>
> there are many Unicode definitions like `const ⊻ = xor` but `∘` does not follow this pattern

~~That being said, in retrospect defining `const ∘ = ComposedFunction` would have made a lot a sense too (and can probably still be done?)~~. On the other hand, `∘` has the property that the 1-ary method is the identity `∘(f) === f`, and the 0-ary method could arguably return `identity` (though currently this is a `MethodError` — [~~a bug?~~ by choice](https://github.com/JuliaLang/julia/issues/52831)), whereas you would want a constructor `ComposedFunction(...)` to always return a `ComposedFunction` instance.

> [@mikmoore](#):
>
> Maybe I’ll get around to adding n-ary versions of `ComposedFunction` one of these days.

What would you return for `n == 1` and `n == 0`? I guess you could just define it for `n ≥ 2`, but then it is still distinct from `∘`.

---

<div class="post-metadata">

**Author:** ![mikmoore](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikmoore/32/31109_2.png) [@mikmoore](https://discourse.julialang.org/u/mikmoore)\
**Post date:** [January 9, 2024, 7:34pm UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/62 "2024-01-09T19:34:33Z")

</div>

Indeed, a difference with `ComposedFunctions` is that it’s a type and therefore should be treated as a constructor. It certainly could return `identity` for zero arguments and the input for 1 argument rather than a `ComposedFunction` (this sort of not-construction is uncommon but I don’t think literally unprecedented), but that would be another debate.

More likely, I would probably just replace the definitions of `∘` with something like `compose` and then set `const ∘ = compose` like the others. But I haven’t been in a situation where I couldn’t just copy-paste `∘` from a REPL so this has never risen high on my list. Especially since there would be some bikeshedding to resolve with the written name. It’s never caused me problems, but it is something I took note of since I usually avoid Unicode when convenient.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [January 12, 2024, 11:36am UTC](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363/63 "2024-01-12T11:36:12Z")

</div>

> [@goerz](#):
>
> Here’s what I’m using: [The “U.S. International - Scientific” Keyboard Layout - Michael Goerz](https://michaelgoerz.net/notes/the-us-international-scientific-keyboard-layout/)

This is super cool, thanks for the link!

> [@jkopper](#):
>
> Counterpoint: Perhaps many people are sufficiently annoyed that they’re opting out of using Julia altogether.
> 
> […] the widespread usage of exotic unicode characters is by far the most aggravating part of the language. […]
> 
> As soon as you require users to have special tooling just to _type their code_, then you have lost a significant portion of developers. Tooling is for _improving_ the coding process, not _enabling_ it. If I can’t ssh into a terminal and edit code with whatever editor happens to be installed, then your language isn’t useful to me. This is a pretty common view, at least outside of the Julia community.

💯

The only saving grace is that it is very possible to mostly opt-out of this madness by simply not using weird characters: There exist very few serious projects that expose their APIs in a unicode-only way.

The primary remaining pain-points for coding are the missing infix xor, and the fact that `Base` / stdlib has some gratuitous uses of things like `\in<TAB>` or `\le<TAB>` (sucks for copy-paste-adapt cycles if you have a non-unicode policy for your projects). If you’re coding in julia, you will read a lot of Base / stdlib code, more than e.g. java devs will need to real jdk libs, due to documentation verbosity.

The other pain-point is that interaction with non-serious projects like discourse posts or slack is made unnecessarily annoying.

> [@stevengj](#):
>
> Is there a particular Unicode-only API you’ve been aggravated by?

Infix xor. I really want a multi-letter infix operator for that.

> [@DNF](#):
>
> As a non-ascii person, by name and language, I find the clinging to an outdated character set quite off-putting. The consequences of this attitude is a source of annoyance and uncertainty every time I book an international plane ticket. Anything that can work to spread the acceptance and use of unicode is great in my book.

I very strongly disagree with your framing that this is a technical problem.

The fundamental issue is a human one: You cannot subvocalize or vocally communicate an unknown/unfamiliar glyph.

It is very difficult for humans to visually distinguish and short-time-remember words composed of unfamiliar glyphs. For this reason, one often transliterates (not translates!) such words, in a way that is somewhat pronouncable (even if the pronounciation is completely wrong).

Imagine having two printed lists, e.g. passenger manifests, and a pen, and having to check off the intersection. Common enough workflow, and a non-computerized fallback is necessary. Imagine one is for loaded baggage and the other is for passengers that have boarded – you need to ensure that all passengers whose baggage has been loaded are actually on the plane.

And now imagine looking at a sea of various names, in their native characters (some Chinese, some Korean names, some have weird African characters you have never seen, some are Hebrew, some Arabic, some Greek, some Cyrillic, some latin). You will be utterly lost trying to figure out which are the same.

The standard solution is to transliterate all these names into some standard character set, which turns out to be latin for historical reasons. Ideally in a way that is superficially pronouncable (irregardless of whether the pronouciation is bogus), because most humans tend to employ their evolved hardware acceleration for audio handling in such tasks (inner voice / subvocalization).

> [@Dan](#):
>
> A solution could be essentially, a “beautifier” option.

This is exactly where I wanted to go. And the first step is modifying the lexer/tokenizer to accept a latin/ascii transliteration, in a way that preserves ASTs.

[Previous page](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363.md?page=2)

[Next page](https://discourse.julialang.org/t/syntax-escape-hatch-for-unicode-haters/108363.md?page=4)