<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Based on commit ‘01317e1a’:<div class=""><br class=""></div><div class="">I think that it makes sense for membership to live outside of a precedence group. An example is if I wanted to add a new assignment operator ( maybe ??= 'assign if nil’), I would want it to have the same precedence as existing assignment operators, including precedence with other custom operators.</div><div class=""><br class=""></div><div class="">Secondly, I think the relationships between precedence groups should be defined outside of an existing precedence group. If I have two libraries that declare operators in their own custom groups, I may need to define a relationship between those groups.</div><div class=""><br class=""></div><div class="">This leads the group declaration itself being just of a name and associativity.</div><div class=""><br class=""></div><div class="">If group precedence is declared externally, there isn’t a need to support ‘>’. Since we are declaring a relationship and not evaluating a relationship, there are side-effects that developers will need to understand if they are trying to comprehend precedence groups in aggregate. Having the groups appear consistently in the same order when defining precedence may help with this.</div><div class=""><br class=""></div><div class="">I still assume these relationships are meant to be constrained to a DAG, although there might be cases where cycles (or even having multiple graphs) would still be unambiguous. I can’t wrap my head around implementation to the point of understanding evaluation if not a DAG yet, nor practical reasons to have cycles in relations.</div><div class=""><br class=""></div><div class=""><div class="">Two groups may be unable to be declared to be equivalent. First, they need to be of the same associativity. Second are also possibilities of graph cycles once the relationships of both groups are overlaid. This is actually the trouble I alluded to in my first email in the thread.</div></div><div class=""><br class=""></div><div class=""><div class="">Finally, an infix operator is part of one and only one group. It might make sense to have a default group (with no associativity) for operators to fall into if they do not declare a precedence group.</div><div class=""><br class=""></div><div class="">Oh wait, Yet another quasi-syntax based on the above:</div><div class=""><br class=""></div><div class="">precedencegroup Additive, associativity: left</div><div class="">precedencerelation Additive < Multiplicative</div><div class="">precedencerelation Range < Additive</div><div class=""><br class=""></div><div class="">infix operator +, group: Additive</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">The question 4 (<span style="font-size:12.8px" class="">`prefix operator ! { }` or `prefix operator !`</span>) seems dead simple, because if we need to declare precedence group in body of infix operators, then other operators should have it for consistency.</div><div class=""><br class=""></div><div class="">It's not.</div><div class="">I suggest an alternative syntax for that:</div><div class="">infix operator <> : Comparative</div><div class=""><br class=""></div><div class="">Colon immediately after the operator may not look the best, but it's the only disadvantage I can find. It looks like inheritance and has similar meaning.</div><div class="">So, in this scheme, all operators will have no body.</div><div class=""><br class=""></div><div class="">I also described two methods to declare that operator belongs to a precedence group: in `members` and in operator declaration.</div><div class="">I suggest that this new syntax looks brief/natural enough to remove `members` option entirely. "There should be one - and preferably only one - obvious way to do it."</div><div class=""><br class=""></div>- Anton</div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-04-08 19:59 GMT+03:00 Антон Жилин <span dir="ltr" class=""><<a href="mailto:antonyzhilin@gmail.com" target="_blank" class="">antonyzhilin@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Thank you for your reply, Chris!<div class="">I was thinking about purging directives from the proposal, and that was what I needed to do it.</div><div class="">So, the proposal is now completely overhauled:</div><div class=""><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank" class="">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div class=""><br class=""></div><div class="">Yes, Maximilian and I have considered operator/precedence groups and they have now moved from alternatives to main part of the proposal.</div><div class=""><br class=""></div><div class="">Questions:</div><div class="">1. Is it OK that associativity is moved to precedence groups and that every operator must belong to a precedence group?</div><div class="">2. Dictionary-like or "functional keywords"? That is, `associativity: left` or `associativity(left)`? So far, only second form has been used somewhere inside declarations.</div><div class="">3. First-lower or first-upper? `additive` or `Additive`?</div><div class="">4. Empty body or no body? `prefix operator ! { }` or `prefix operator !`?</div><div class=""><br class=""></div><div class="">Just in case, some questions/concerns copied from previous discussion:</div><span class=""><div class=""><br class=""></div><div class=""><div style="font-size:12.8px" class="">1. All precedence groups have a "parent".</div><div style="font-size:12.8px" class="">It means, all operators will want to have precedence higher than Comparative or Ternary, or, at least, Assignment.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">2. Moreover, I could not find any case where I had to write anything other than precedence(>, ...)</div><div style="font-size:12.8px" class="">Of cause, I cheated, because I can control all these declarations.</div><div style="font-size:12.8px" class="">Mere people will have to use `<` to say that Additive, for example, should have less priority than their custom operator.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">But... can you build a custom operator where `<` will actually be needed? I have even stronger doubts on `=`.</div><div style="font-size:12.8px" class="">Maybe we can even contract this feature to `parent(Comparative)` or something without losing any expressivity?</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">3. Can we allow operators to have less priority than `=`?</div><div style="font-size:12.8px" class="">If yes, can you give an example of such operator?</div></div><div style="font-size:12.8px" class=""><br class=""></div></span><div style="font-size:12.8px" class="">- Anton</div><div class=""><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-04-08 8:59 GMT+03:00 Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">First of all, sorry for the delay. I still hope to finish the discussion and push the proposal to review for Swift 3.0.<div class="">Link for newcomers:</div><div class=""><a href="https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md" target="_blank" class="">https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md</a></div><div class=""><br class=""></div><div class="">Sadly, I've moved into the territory opposite to what I had in mind in the beginning: absense of conflict resolution.</div><div class="">I wanted lightweight directives, but am moving to closed precedence groups.</div><div class=""><br class=""></div><div class="">It's just IMHO, and I think I just need input on this from more people. I still have not heard anything from Core team.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Hi Антон,</div><div class=""><br class=""></div><div class="">I’m sorry for the delay, I have been out of town recently. I haven’t read the upstream thread so I hope this isn’t too duplicative. Here is my 2c:</div><div class=""><br class=""></div><div class="">- I completely agree that numeric precedences are lame, it was always the “plan” that they’d be removed someday, but that obviously still hasn’t happened :-)</div><div class="">- I definitely agree that a partial ordering between precedences is all that we need/want, and that unspecified relations should be an error.</div><div class=""><br class=""></div><div class="">That said, I feel like #operator is a major syntactic regression, both in consistency and predictability. We use # for two things: directives (like #if) and for expressions (#file). The #operator is a declaration of an operator, not an expression or a directive. For declarations, we consistently use a keyword, which allows contextual modifiers before them, along with a body (which is sometimes optional for certain kinds of decls). I feel like you’re trying to syntactically reduce the weight of something that doesn’t occur very often, which is no real win in expressiveness, and harms consistency.</div><div class=""><br class=""></div><div class="">Likewise #precedence is a relationship between two operators. I’d suggest putting them into the body of the operator declaration.</div><div class=""><br class=""></div><div class="">OTOH, the stuff inside the current operator declaration is a random series of tokens with no apparent structure. I think it would be reasonable to end up with something like:</div><div class=""><br class=""></div><div class="">infix operator <> {</div><div class=""> associativity: left</div><div class=""> precedenceLessThan: *</div><div class=""> precedenceEqualTo: -</div><div class=""> }</div><div class=""><br class=""></div><div class="">Or whatever. The rationale here is that “infix” is primal on the operator decl (and thus is outside the braces) but the rest of the stuff can be omitted, so it goes inside.</div><div class=""><br class=""></div><div class="">Just in terms of the writing of the proposal, in the "Change precedence mechanism” keep in mind that swift code generally doesn’t care about the order of declarations (it doesn’t parse top down in the file like C does) so the example is a bit misleading.</div><div class=""><br class=""></div><div class="">Question for you: have you considered introducing named precedence groups, and having the relationships be between those groups? For example, I could see something like:</div><div class=""><br class=""></div><div class=""><span style="white-space:pre-wrap" class=""> </span>operator group additive {}</div><div class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>operator group multiplicative { greaterThan: additive }</div><div class=""><div class=""><span style="white-space:pre-wrap" class=""> </span>operator group exponential { greaterThan: additive }</div></div><div class=""><br class=""></div><div class="">Then:</div></div><div class=""><br class=""></div><div class=""><span class=""><div class="">infix operator + {</div><div class=""> associativity: left</div></span><div class=""> precedence: additive</div><div class=""> }</div><div class=""><div class="">infix operator - {</div><div class=""> associativity: left</div><div class=""> precedence: additive</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">etc.</div></div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">-Chris</div></font></span></div></div></blockquote></div><br class=""></div></div></div></div>
</blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>