"Is it coherent to ask whether any two things are equal"
def: "yes" is the reply that follows recognized equality and "no" is the
reply that does not
obs: recognition of equality is situated { ≟(2, 2) ≟(2, *2*) ≟(2, teuw)
}
yes
On Thursday, September 10, 2015 at 11:54:52 PM UTC-4, Jeff Bezanson wrote:
>
> 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] <javascript:>>
> 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
> >> >>
> >> >
>
