Just to clarify, with currently proposed behaviour, corresponding expressions would be parsed as follows:<div><br></div><div>a + b * c // a + (b * c)</div><div>a * b ^ c // a * (b ^ c)</div><div>a ^ b + c // a ^ (b + c)</div><div><br></div>The compiler would look only at explicitly stated precedence between two given operators and would not try to use transcendency.<div><br></div><div>Having said that, at least two opinions were that operators should form a DAG by precedence. If no objections are stated, I will change the proposal accordingly, also without future directions.<br><div><div><br>On, Apr 4, 2016, Ross O'Brien wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How is a non-transitive relation different from a conflict?<div>If we use:</div><div>#precedence(+, lessThan: *)</div><div>#precedence(*, lessThan: ^)</div><div>#precedence(^, lessThan: +)</div><div>Surely that should be an error, even with none of the operators actually used?</div><div><br></div><div>The compiler would be asked to verify two things: that the relationships of all operators in the program can be expressed with a topological ordering, and any pair of operators used together in an expression in the program has an unambiguous precedence in that ordering. (I have no idea how relatable this comparison actually is, but it seems like it would be a simpler problem than analysing NSLayoutConstraints for violations.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 7:49 AM, Антон Жилин <span dir="ltr"><<a>swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In the poposed model, all relations are not transitive. Example:<div><br><div><span><div>#precedence(+, lessThan: *)</div><div>#precedence(*, lessThan: ^)</div></span><div>1 ^ 2 + 3 // error</div><div>#precedence(+, lessThan: ^)</div><div>1 ^ 2 + 3 // now ok</div><div><br></div><div>Would it be better to have such indirect relations inferred? Or would it put too much responsibility on the compiler?</div><div>Maybe add it to future directions?</div><div><br></div><div>Cycles of length >2 are also allowed. This was not added intentionally, but follows from other specified rules.</div><div>Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit stretched, otherwise quite logical.</div><span><div><br></div><div>> <span style="font-size:12.8px">- I wonder if there are cases in the standard operators which would be better modeled as a non-linear chain.</span></div></span><div><span style="font-size:12.8px">In the standard library, non-linearity will be primarily used to break a single hierarchy into multiple small ones. I doubt that any trees or cycles will form, although that would be good news.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">- Anton</span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-04 8:55 GMT+03:00 David Waite <span dir="ltr"><<a>david@alkaline-solutions.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Interesting model!<div><br></div><div>If I understand correctly: this changes the precedence from being based on a numeric value, to being represented as a bit of a DAG of precedence groups. A precedence group is defined implicitly for each operator, with one group around each set of operators where equalTo has been declared.</div><div><br></div><div>The groups are lazily evaluated, so if an expression can be resolved without ambiguity due to lack of reachability between two individual operators in the DAG, there is no issue/error.</div><div><br></div><div>Comments:</div><div>- I wonder if there are cases in the standard operators which would be better modeled as a non-linear chain. The compiler could warn around usage which is defined by operator precedence, but is commonly considered ambiguous or error prone. </div><div><br></div><div>For example, if users commonly get confused about the conjunctive and disjunctive levels (logical ‘and’ and ‘or’) being different levels with precedence, you could just omit the lessThan relationship between the two of them. The compiler would then error on ambiguous cases, prompting the user to use parenthesis.</div><div><br></div><div>- I’d prefer instead of operator precedence groups just being implicit by use of #precedence equalTo, that the operators are bound to a group explicitly. Something like</div><div>#precedence(+, group: “additive”)</div><div>#precedence(“additive”, lessThan: “multiplicative”)</div><div><br></div><div>However, this may create more issues than it solves (two frameworks creating their own custom operators, putting them in custom precedence groups, and the consumer decides the two precedence groups are really equivalent)</div><span><font color="#888888"><div><br></div><div>-DW</div></font></span><span><div><br></div><div><div><blockquote type="cite"><div>On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">Swift 2.2 is out, and I restart discussion on syntax for custom operators. I insist that this time we should focus less on linguistic aspects.<div><br></div><div><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div><br></div></div></div></blockquote></div><br></div></span></div></blockquote></div><br></div></div></div></div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div>