I think there are some viable options here, for example making numbers non-iterable, and/or doing some combination of checks and conversions. However splitting Base for this purpose is nowhere near viable. It's a cop-out design: we can't decide which behavior is right, so we just give you both and make you pick. Very confusing. If you need to do something extra to enable convenient mode, then it's not convenient. Or, on the other side, if every style guide is going to recommend enabling strict mode because otherwise your program is a mess, why provide an alternative at all?
Unfortunately, at the bottom of this issue there is a fundamental philosophical debate that may not be possible to resolve with design choices. Namely, is equality a total theory? Is it coherent to ask whether any two things are equal, or do the arguments first have to clear some hurdle of commensurability? It's no secret that julia is biased from the beginning towards the former, no-hurdles view. It would be great if the two sides in this debate could just get along somehow, but it doesn't seem like something we're likely to resolve here. On Thu, Sep 10, 2015 at 5:20 PM, <[email protected]> wrote: > 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]> 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 >> >> >> >
