I couldnât disagree with you more on this!

If you guys are touting Julia as âA Fresh Approach to Câ, then fine, feel free to tell users who get caught in semantic traps that they ought to use Lint. But it seems that you actually want to tout Julia as a fresh approach to Matlab, R and Numpy, You should consider how Matlab, R and Numpy might deal with this.

Indeed, there is a historical comparison. In the early 1990s, Matlab suffered from the following shoot-yourself-in-the-foot scenario. In the expression `a(v)`

, where `a`

was a vector length `n`

and `v`

was a vector of all 1âs of length n, the meaning was ambiguous. This could either mean boolean addressing, in which case the answer should be `a(1:n)`

, or it could mean an integer vector address, in which case the answer should be `a(1)*ones(1,n)`

. The Matlab interpreter chose one of the two ways to resolve the ambiguity. Programmers who overlooked the ambiguity (even experienced ones like me) and expected the other resolution incurred subtle program bugs that might not occur in the first 9999 loop iterations but would strike in the 10000th.

Mathworks fixed this problem by introducing a new type, `logical`

, and forbidding the use of ordinary integers for boolean addressing. This change broke almost everyoneâs code, but at the time I recall most serious Matlab users approved of the change.

Here is my proposal: for the code in my previous post, the compiler should say:

`WARNING: Shadowing, +(::Any,::Any) hides Base.+. Use @OK_to_shadow macro to suppress this message. In f(::Int64, ::Int64), test_plus.jl:4`

Then I could either fix the bug, or if I had really intended to redefine +, then I would change my code to

```
tests = [a - b == 0, a * b == 0, (@OK_to_shadow a + b = 0)]
```

Is that really so annoying to experts? Compare it to the hours of annoyance by the OP and myself in trying to figure out this semantic trap.