# Why are numeric comparisions constrained to support only two args?

**URL:** <https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462>\
**Category:** New to Julia\
**Tags:** question, proposal\
**Created:** [August 19, 2017, 2:14pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462 "2017-08-19T14:14:36Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 20, 2017, 2:36pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/21 "2017-08-20T14:36:03Z")

</div>

> [@Sighoya](#):
>
> But why support numeric comparision short circuit evaluation when they ARE functions.

Comparison ops are indeed functions, but when you chain them in code, they are expanded into a short-circuited structure.

```julia
julia> expand(:(1 < 2 < 3))
:(begin 
        unless 1 < 2 goto 3
        return 2 < 3
        3: 
        return false
    end)

```

All of these things are documented.

Getting back to your original question: proposals about basic features of the language are OK, but note that at this point the barrier to entry is high: they have to give a substantial advantage. In any case, putting in some work beforehand about understanding the language as is usually pays off.

---

<div class="post-metadata">

**Author:** ![Sighoya](https://avatars.discourse-cdn.com/v4/letter/s/a87d85/32.png) [@Sighoya](https://discourse.julialang.org/u/Sighoya)\
**Post date:** [August 20, 2017, 2:53pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/22 "2017-08-20T14:53:07Z")

</div>

@Tamas_Papp  
Fine, and why we could not expand && and || with the same trick and additionally use && and || as a function of two args like for numeric comparisions?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 20, 2017, 2:56pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/23 "2017-08-20T14:56:47Z")

</div>

You are missing the point of `||` and `&&`: that they are _not functions_. This is key to their semantics.

---

<div class="post-metadata">

**Author:** ![Sighoya](https://avatars.discourse-cdn.com/v4/letter/s/a87d85/32.png) [@Sighoya](https://discourse.julialang.org/u/Sighoya)\
**Post date:** [August 20, 2017, 2:57pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/24 "2017-08-20T14:57:59Z")

</div>

@Tamas_Papp  
This is clear to me, but why they are not functions?

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [August 20, 2017, 3:03pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/25 "2017-08-20T15:03:45Z")

</div>

> [@Sighoya](#):
>
> This is clear to me, but why they are not functions?

You have `|` and `&` for that.

---

<div class="post-metadata">

**Author:** ![Sighoya](https://avatars.discourse-cdn.com/v4/letter/s/a87d85/32.png) [@Sighoya](https://discourse.julialang.org/u/Sighoya)\
**Post date:** [August 20, 2017, 3:14pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/26 "2017-08-20T15:14:06Z")

</div>

I thought & and | was binary only. Ok but the use of  
&(true, false) gives me  
ERROR: syntax: malformed expression  
Stacktrace:  
[1] macro expansion at ./REPL.jl:97 [inlined]  
[2] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:73

Do I have to escape something?

---

<div class="post-metadata">

**Author:** ![PabloZubieta](https://avatars.discourse-cdn.com/v4/letter/p/ee7513/32.png) [@PabloZubieta](https://discourse.julialang.org/u/PabloZubieta)\
**Post date:** [August 20, 2017, 3:17pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/27 "2017-08-20T15:17:42Z")

</div>

Right now you need `(&)(x, y)` to use `&` in a function call (you could assign another symbol to it and use that instead, though).

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [August 20, 2017, 3:23pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/28 "2017-08-20T15:23:50Z")

</div>

> [@Sighoya](#):
>
> I thought & and | was binary only.

Well, booleans are single bit binary number so it works exactly the same.

> [@Sighoya](#):
>
> &(true, false) gives me

You can also just use it as operator

And yet another reason `&&`/`||` shouldn’t be functions (and to a less degree why allow multiarg `<` can be confusing) is that people will want to overload them. However, that overload will either not be called when it’s used as operator or it’ll conditionally turn off short circuit (C++) and both are really bad options (the latter being especially bad for a dynamically typed language like julia). Of course for comparison, you can already define multi-arg version that’ll not get called in `a < b < c ...`

---

<div class="post-metadata">

**Author:** ![Sighoya](https://avatars.discourse-cdn.com/v4/letter/s/a87d85/32.png) [@Sighoya](https://discourse.julialang.org/u/Sighoya)\
**Post date:** [August 20, 2017, 3:34pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/29 "2017-08-20T15:34:19Z")

</div>

@PabloZubieta  
Thanks, it works now.

@yuyichao  
I see the difference between && and &:  
expand(:(1 & 1 & 1))  
:((1 & 1) & 1)

, whereas  
expand(:(1 && 1 && 1))  
:(begin  
unless 1 goto 6  
unless 1 goto 4  
return 1  
4:  
return false  
6:  
return false  
end)

The difference is, && is lazy whereas & strict in evaluation.

To preserve the lazyness of the numeric comparisions one has to introduce strict variants of it, but this will blow up the language.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [August 20, 2017, 7:49pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/30 "2017-08-20T19:49:14Z")

</div>

> [@yuyichao](#):
>
> May not be a big deal assuming no one is going to write chained comparison as function calls…

Exactly. I don’t see why it would be a problem for `a < b < c` to be different (in short-circuit semantics, not in value) from `(<)(a,b,c)`.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [August 20, 2017, 7:57pm UTC](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462/31 "2017-08-20T19:57:33Z")

</div>

> [@stevengj](#):
>
> Exactly. I don’t see why it would be a problem for a \< b \< c to be different (in short-circuit semantics, not in value) from (\<)(a,b,c).

Usually not, until someone overloads multiarg `<`. It’s not really new although defining it in base will encourage this thought. It’s a bit unsatisfying but I’m kind of OK either way…

[Previous page](https://discourse.julialang.org/t/why-are-numeric-comparisions-constrained-to-support-only-two-args/5462.md?page=1)