In my eyes this is a non issue. Symbols are symbols, 'x' is a symbol, '³' is a symbol, '∛' is a symbol. They all work the same. When you allow unicode it is always possible to write confusing code.
On Friday, July 3, 2015 at 5:25:00 AM UTC+2, Scott Jones wrote: > > Starting in > https://github.com/JuliaLang/julia/pull/11927#issuecomment-117374003 and > continuing on in > https://github.com/JuliaLang/julia/issues/11966#issuecomment-118212265, > I had raised an issue that can cause confusion to newcomers to Julia, and > potentially lead to programming errors if one isn't careful. > There is also the issue of inconsistency within Julia, where certain > mathematical operations are actually treated as operations, > and others that look like taking something to a power, i.e. with > superscripts, are treated as identifiers. > > I am *not* suggesting that this should be changed in Julia (people got a > bit upset with that idea), but rather trying to propose ways > that the use of superscripts as part of variable names can be made much > safer in practice. > > For example: > > julia> cube(x) = x³ > cube (generic function with 1 method) > julia> cube(3) # Silly me, I think I'll get 27 > ERROR: UndefVarError: x³ not defined > in cube at none:1 > julia> x³ = 4242 > julia> cube(3)42 > > julia> ∛x³ >> 3.4760266448864496 > > > Besides documenting this, as @Ismael-VC has suggested, I think that it > might be useful for the compiler to try to catch some of the cases that > could actually lead to programming errors. In the above case, the compiler > could detect that a variable of global scope was being used, along with a > local variable that is the same except for trailing superscript(s), and > give a warning. > Another possible programming error that can occur if one mistakenly > thought that `³` was performing a cube operation, is that the variable x is > updated, but the cached cube value in the variable `x³` is not. That could > also be caught by the compiler. > > What do people think? > Are there any other things that could be done besides documentation, to > help make using these types of identifiers easier and not error-prone? > > > >
