# Guarantees on order of evaluation?

**URL:** <https://discourse.julialang.org/t/guarantees-on-order-of-evaluation/96259>\
**Category:** General Usage\
**Created:** [March 17, 2023, 7:55pm UTC](https://discourse.julialang.org/t/guarantees-on-order-of-evaluation/96259 "2023-03-17T19:55:29Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 18, 2023, 7:50pm UTC](https://discourse.julialang.org/t/guarantees-on-order-of-evaluation/96259/7 "2023-03-18T19:50:01Z")

</div>

I believe everything is evaluated left-to-right (that’s a guarantee except if you control with parenthesis, and also precedence rules apply), except for, yes (there’s a good reason for this, to allow it undefined, but I think in practice for now, if may also be left-to-right):

> The only thing I have been able to find is that the order of evaluations in a chained comparison is not defined.

I recall however one suggestion to break that rule for 2.0 (may never be implemented, meant for matrices if I recall, the title is misleading, doesn’t justify this issue):

> <https://github.com/JuliaLang/julia/issues/34999>
>
> @ChrisRackauckas and I was just talking and we were wondering why we are parsin…g \`1 + 2 + 3\` as \`Expr(:+, 1, 2, 3)\`.
> While I can see how that makes the parsers job easier it seems to make it harder for type-inference since instead of just
> having on \`+\` method for integers we now have ~16, added to that is Chris infamous tendencies to create very long expressions
> which causes things to break down one you reach \*\*a\*\* limit. (and as demonstrated before no matter how large \`N\` at some point it will be to small).
> 
> Is there a strong reason that I am missing for why we keep parsing it as a single expression? Macro-writers already need to program defensively
> against both forms and it seems to me normalizing earlier would be better.

You can also change to more optimal way of evaluating with a macro (for matrix multiplies, then data dependent, I forget the package that implements it, maybe those in the following discussion, except they are outdated).

> [@Why is multiplication A\*B\*C left-associative (\`foldl\`) not right-associative (\`foldr\`)?](https://discourse.julialang.org/t/why-is-multiplication-a-b-c-left-associative-foldl-not-right-associative-foldr/17552):
>
> This behaviour is a bit surprising: julia\> A = randn(50,50); x = randn(50); julia\> @btime A\*A\*x; 10.064 μs (3 allocations: 20.17 KiB) julia\> @btime A\*(A\*x); 736.336 ns (2 allocations: 1.06 KiB) julia\> @btime (A\*A)\*x; 11.066 μs (3 allocations: 20.17 KiB) I’m curious on the design choice, as matrix \* vector is much more common than say vector’ \* matrix.

> So what I really want is short-circuit evaluation for multiplication 3, which doesn’t seem to exist?

Seems would be doable with a macro.

---

_[View the full topic](https://discourse.julialang.org/t/guarantees-on-order-of-evaluation/96259)._