Yes, on GitHub, I'd already suggested that (and was pilloried for being off-topic on an issue that had been raised because of me in the first place. Will Lint.jl be able to detect all of the cases that I pointed out? (I haven't tried it yet, been meaning to)
On Friday, July 3, 2015 at 11:27:34 AM UTC-4, Kevin Squire wrote: > > Lint.jl would be a good place to add appropriate warnings. > > Cheers, > Kevin > > On Friday, July 3, 2015, Scott Jones <[email protected] <javascript:>> > wrote: > >> I would rather have them as well defined operators, rather than allowed >> as parts of identifiers, which would have been more consistent with other >> things in Julia, like sqrt() and cbrt() using the Unicode symbols as prefix >> operators, however, the reactions included things like "pry them from my >> cold, dead hands", plus other people pointed out other cases where the >> superscript wasn't really doing a ^2 or ^3 operation. >> That's why I was trying to brainstorm on ways the language could be made >> tighter, and at least warn about some of the potential >> cases of programming errors due to the confusion this can cause, without >> prying the beloved superscripts from their identifiers. >> >> The documentation part is already happening (@Ismael-VC seems to be >> absolutely full of energy!) >> >> On Friday, July 3, 2015 at 9:39:48 AM UTC-4, Tom Breloff wrote: >>> >>> I think I've flipped my position back and forth 6 times in the last few >>> minutes while thinking about this. The mathematician in me wants those >>> special characters to be well defined operators with the expected >>> precedence, but the computer scientist in me thinks that's a horribly >>> stupid idea for reasons that Scott and others have pointed out. The sad >>> thing is that, whatever the decision, it needs to be done in the core >>> parsing for it to be useful, so it can't practically be a user-defined >>> decision (unless of course it becomes a flag you can set when making or >>> running Julia). >>> >>> On that last point... how hard would it be to define certain operators >>> like the square, etc, that sit within #ifdef blocks in the parser? I guess >>> even with that ability, you'd potentially be mixing code of both forms >>> which would be confusing at the very best.... so I guess we have to choose >>> one. >>> >>> At a minimum... gotta document! >>> >>> On Thursday, July 2, 2015 at 11:25:00 PM UTC-4, 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? >>>> >>>> >>>> >>>>
