Disallow the Unicode "Braille Patterns" block for code (e.g. variables, and function names), but not in strings

[PallHaraldsson]

Braille is currently allowed, but most likely not used in any code. I.e. these 256 symbols https://en.wikipedia.org/wiki/Braille_Patterns

It may seem unfriendly to blind people, but it's actually meant to solve (some of the) problems for blind people using Julia. See issues at this thread:

https://discourse.julialang.org/t/julia-and-braille/77002/10

This is a breaking change, though likely one of those "technical breaking". I don't think it needs to wait for Julia 2.0.

[JeffBezanson]

This sounds right to me. Is there an authoritative reference of some kind we can consult to see what the best practices are? That would make it very easy to justify this.

[PallHaraldsson]

I don't know, I was just trying to help on discourse, reading way more than I ever did on (different) Braille (including for Greek for math and Icelandic etc). See on discourse. Disallowing this will help blind people, because they can't see the difference, us non-blind will, but aren't likely to use Braille (except for the sparse matrix trick).

[Satvik]

The American Foundation for the Blind has a list of best practices, focused mostly on websites: https://www.afb.org/consulting/afb-accessibility-resources

I couldn't find an answer to this specific question, so I emailed them and will reply if I hear back.

[KristofferC]

This doesn't make sense to forbid on the language level to me. Feels like a style guide entry or something along those lines is more suitable.

[PallHaraldsson]

Julia is likely the only language to allow the Braille symbols (and otherwise extensive Unicode), e.g. allowing:

julia> ⠗ = 1;
julia> R = 2;  # R ASCII letter maps to the above Braille, but only for display purposes

I'm copying this example from my discourse post to show the problem. This would trick the blind, as they wouldn't be able to see the difference, and I doubt they could (easily) type that in. Only us seeing people, maybe using those Braille patterns trying to be well meaning.

[KristofferC]

This would trick the blind

This is a very small subset of possible variable names that "would trick the blind". Again, this seems like something that should be e forced via policy and it on the language level. The same argument here could be applied to any Unicode variable.

[stevengj]

The same argument here could be applied to any Unicode variable.

Yes, there are a huge number of confusable Unicode characters — if someone wants to write deceptive code, they can easily do so even for programmers who are not visually impaired.

And if they aren't intentionally trying to write deceptive code, I find it hard to imagine any programmer using Braille characters for variable names; are there any extant examples of this?

[vtjnash]

I assume the idea here is to avoid a blind programmer confusing themselves if they typed a braille character and meant to enter the regular character. But I don't see how that would accidentally happen too easily, or how it is different from me writing the wrong character out of similar looking ones.

[PallHaraldsson]

I find it hard to imagine any programmer using Braille characters for variable names; are there any extant examples of this?

Not that I know of, I'm thinking of disallowing before that happens (a PR could be merged on 1.9-DEV and a later PkgEval would give some assurance). If that were to happen it would be an actual breaking change, not just a technical one.

This isn't about "intentionally trying to write deceptive code", but in case someone thought using the symbols a good idea, maybe blind people?

forced via policy

Well, I think it should. Julia is likely the only language to allow the Braille symbols. I'm not sure if it happened by oversight (pun intended), or was thought to be actually helpful. It's not helpful to anyone.

[KristofferC]

It's not helpful to anyone.

 ⠙ = '⠙'

Doesn't look useless to me.

[mgkuhn]

This seems a non-issue to me. Unicode contains a huge number of exotic and rarely-used characters, of which the Braille symbols are only a tiny tiny fraction. Any Braille display for UTF-8 plaintext files and terminal screens needs to implement a transcription function that first maps all possible Unicode characters to sequences of Braille symbols before they can be displayed as Braille. Such a mapping function will likely try to follow common and domain-specific Braille acronyms as far as possible, and then use standard generic fallbacks for anything else, such as the character name from the Unicode database (e.g. [BRAILLE PATTERN DOTS-125]) or even just the hexadecimal code (e.g. U+2813). Therefore the Unicode Braille range will likely be treated in exactly the same way as any other rarely used Unicode character.

There seems no demonstrated need, and nothing gained, by doing anything special here. Wether a user wants the 256 Unicode Braille symbols to be passed-through as they are, or displayed in a fall-back notation, will be up to how the Braille-terminal user configures their local mapping preferences table.

And regarding the (independent) question of what symbols should be allowed in Julia identifiers, I'd simply first consult UTR #31, the Unicode standard for use of Unicode characters in programming-language identifiers, and would hope for a Julia-specific justification for proposals to deviate from that in Julia.

[stevengj]

And regarding the (independent) question of what symbols should be allowed in Julia identifiers, I'd simply first consult UTR #31, the Unicode standard for use of Unicode characters in programming-language identifiers, and would hope for a Julia-specific justification for proposals to deviate from that in Julia.

We long ago decided to deviate from UTR#31 in order to allow a much broader variety of Unicode symbols in Julia code. For example, the default recommendations of UTR#31 would disallow numeric subscripts/superscripts in identifiers, which are extremely useful in representing mathematical notation, nor would the many mathematical binary operators be supported.