Not sure. Your best bet is to open up an issue in Lint.jl. Tony (the maintainer) is usually quite responsive.
Cheers, Kevin On Fri, Jul 3, 2015 at 8:39 AM, Scott Jones <[email protected]> wrote: > 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]> 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? >>>>> >>>>> >>>>> >>>>>
