\Bbbone is not valid input

[dpsanders]

I wanted to use \Bbbone (𝟙) as a variable name (on latest master) but it gives the following error:

julia> 𝟙
ERROR: syntax: invalid character "𝟙"

Other less common characters, such as
\mbfitsansvarpi, just above it in the Unicode input list do work.

Is this deliberate since it's "sort of a number"?

[dpsanders]

I see that a𝟙 is a valid variable name, which strengthens my hypothesis, but I don't see any distinction being made in latex_symbols.jl at a glance.

[simonbyrne]

Same with \Bbbzero (𝟘) all \Bbb digits.

[jiahao]

There's a place in the parser that checks if a character is valid to place at the beginning of an identifier name.

[dpsanders]

OK, I see, thanks. Maybe these symbols could be included as allowed?

[sbromberger]

Does this mean that it might be possible to do 𝟙 = 2? That seems... ripe for abuse :)

[jiahao]

Well, 𝟙 is quite commonly used for the identity matrix or the matrix of all ones. Being able to use it as a variable name is a valid use case.

[sbromberger]

Having to squint to determine whether a = 1 means "assign the value one to a" or "assign some other variable to a" will make code maintenance a nightmare unless steps are taken to document the use of this variable, in which case you might as well use another variable.

[jiahao]

"Get a better font" :)

[sbromberger]

"Get a better font" :)

AWESOME. :) I don't really have a large dog in this fight: I can't imagine ever using this but I recall the security / phishing problems we had when unicode characters were allowed in URLs, and I imagine something similar can happen in Julia. It was a bad idea for URLs, and it seems like some of the same problems might be carried over here.

I can't wait to try this out though.

[jiahao]

I don't think we should conflate this issue with #9744.

[JeffBezanson]

This character is numberlike and so is not allowed to start an identifer. However we don't parse it as a number either, hence the current error. I think this situation is reasonable.

You tend not to see fonts using "1" for "𝟙" (has anybody seen this?); you usually get a reasonable glyph or else some nasty replacement character.

I don't think it's the place of a programming language to try to ban characters. I acknowledge the security problems caused by unicode in URLs, but I find it circuitous logic to say that unicode should be disallowed in hopes of slightly decreasing the surface area for phishing attacks.

[sbromberger]

@JeffBezanson

I find it circuitous logic to say that unicode should be disallowed in hopes of slightly decreasing the surface area for phishing attacks.

That's not what I was suggesting - sorry for any misunderstanding. I think that the current approach (as I understand it) of not allowing "numberlike" characters to start identifiers is the correct one.

... but I see that a commit has already been made to allow this. I'll just go once more on the record that I think it's a bad idea, and will move on.

[JeffBezanson]

The proposed change was not merged; seems this was decided against.

[simonbyrne]

The other discussion seems to have gotten rather distracted, so I'm not sure it was ever really resolved.

FWIW, I would still be in favour of allowing these, as well as the various vulgar fractions (½, etc.)

[sbromberger]

@simonbyrne just to clarify (and to refresh my memory) - is it your suggestion that the vulgar fractions would be "numberlike" in that they wouldn't be allowed to be (or to start) variable names?

[simonbyrne]

Actually I'm not sure: I was just throwing them into the mix as they could be useful, but currently get parsed as an error. Ideally I would like to use them as

y = exp(½*x)

So I guess they should act like numbers, perhaps as rationals? (though in that case we should try to get some performance optimisations so that when used with floats they are inlined to the appropriate constants)

[sbromberger]

As long as they're constants (that is, they can't be arbitrarily redefined) I'd be in favor of this; but if users can assign them as variables (i.e., ½ = 0.25 or even ½ = "cheese"), I'd have some concerns. This is the way we get Mars landers to crash on entry :)

[JeffBezanson]

We could potentially parse the vulgar fractions as numeric literals. Unlike \Bbbone they seem to have totally unambiguous meanings.

[jiahao]

We could potentially parse the vulgar fractions as numeric literals.

One possible argument against doing this is in writing code that caches computation of expensive divisions, e.g. naming a variable ⅓x that caches the division x/3. Note that we already allow x² to mean anything, even though it's convenient to cache the repeated use of a squared quantity.

[JeffBezanson]

Both the syntaxes 2x (multiply) and x2 (variable) exist, and we can continue that here. While x² is a variable name like x2, ²x is currently a syntax error. So we could have ⅓x multiply and x⅓ be a variable name. Granted it's not as natural a way to name the variable, but at least it provides some way to get both behaviors.

[JeffBezanson]

The only change I can imagine making here is allowing these characters in initial position (for identifiers, or perhaps as numeric literals in the case of fractions), in which case it will be non-breaking. Moving out of 1.0.

[Keno]

Fixed by #32838.