Jeff, Thanks very much for pointing out the issue that I opened last year. I had thought incorrectly that I had raised the matter of type-checking with 'in' on this newsgroup rather than on github, which explains why I couldn't locate the previous discussion in my first post today.
I am bringing the subject up again because I understand Julia much better now, and I have realized that a main cause for the loose type-checking is the plethora of methods in Base (e.g., the start/next/done functions that turn a Float64 into an iterable) that create certain conveniences but also create many possibilities for programmer blunders. Now that I understand the cause of the loose type-checking, I am able to propose a (relatively) simple solution, which is to split Base into two parts: essentials and conveniences -- Steve On Thursday, September 10, 2015 at 2:31:39 PM UTC-4, Jeff Bezanson wrote: > > If anybody is interested and missed it the first time around, there is > some good discussion of this in > https://github.com/JuliaLang/julia/issues/7903. > > On Thu, Sep 10, 2015 at 2:01 PM, Randy Zwitch > <[email protected] <javascript:>> wrote: > > How do you enumerate all of the cases that are "oddball"? > > > > julia> [1,2,3] in Any[[1],[2],[3],[1,2,3]] > > > > true > > > > > > julia> [1,2,3] in [[1],[2],[3],[1,2,3]] > > > > false > > > > > > In the first case, because I declare the array of type "Any", I have an > > Array of Arrays (Array{Any, 1}). In that case, the "in" statement is > > perfectly valid to test for and is true. > > > > > > In the second case, you get false. What's difficult here is that I think > the > > compiler is confused due to the change in concentation syntax: > > > > > > julia> typeof([[1],[2],[3],[1,2,3]]) > > > > WARNING: [a,b,...] concatenation is deprecated; use [a;b;...] instead > > > > in depwarn at ./deprecated.jl:73 > > > > in oldstyle_vcat_warning at ./abstractarray.jl:29 > > > > in vect at abstractarray.jl:32 > > > > while loading no file, in expression starting on line 0 > > > > Array{Int64,1} > > > > > > > > I'm not proposing a solution, just highlighting that it would be pretty > > difficult to protect everyone from themselves. At some point, people > need to > > be precise about what they mean. > > > > > > > > > > On Thursday, September 10, 2015 at 12:59:59 PM UTC-4, > [email protected] > > wrote: > >> > >> About a year ago I proposed on this forum that 'in' should do more > >> type-checking. For example, the expression > >> > >> [1,2,3] in [1,2,3,4] > >> > >> is almost certainly a programmer error. But Julia accepts it without > >> complaint and returns 'false'. I myself have had problems with the > wrong > >> version of 'in' getting called and nonsensical results returned. > >> > >> The argument raised against this proposal was the following. According > to > >> Julia semantics, "a in b" is equivalent to > >> > >> for x in b > >> if x==a > >> return true > >> end > >> end > >> return false > >> > >> But in fact, as the Julia 0.4 recent masters show, there are at least > two > >> cases in which 'in' does not follow these semantics and returns an > error if > >> it thinks the programmer made a mistake. (See the trace below-- both > are > >> cases where Julia 0.4 changed behavior from 0.3). > >> > >> It is important for Julia to be vigilant about catching obvious > programmer > >> errors. This will help improve its chances for use in introductory > >> programming courses at universities, among other reasons. > >> > >> I propose the following: In Julia 0.5, Base should be broken up into > Base > >> and ExpansiveBase. Functions like in(x::Any,itr::Any) from reduce.jl > or > >> start(x::Number) from number.jl that allow oddball user code to be > accepted > >> by the compiler would be put into ExpansiveBase. The semantics for > >> 'in(a,b)' when only Base is loaded should be either > typeof(a)==eltype(b) or > >> that there exists a method convert(eltype(b),a). > >> > >> -- Steve Vavasis > >> > >> > >> julia> 0 in IntSet() > >> WARNING: stored zeros in IntSet is deprecated > >> in depwarn at deprecated.jl:63 > >> in in at intset.jl:163 > >> while loading no file, in expression starting on line 0 > >> false > >> > >> julia> (1,2) in Dict{Any,Any}() > >> ERROR: Associative collections only contain Pairs; > >> Either look for e.g. A=>B instead, or use the `keys` or `values` > >> function if you are looking for a key or value respectively. > >> in in at dict.jl:13 > >> > > >
