<div dir="ltr">Inline:<br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-09 0:17 GMT+03:00 David Waite <span dir="ltr"><<a href="mailto:david@alkaline-solutions.com" target="_blank">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">Based on commit ‘01317e1a’:<div><br></div><div>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></blockquote><div><br></div><div>Right, the proposal currently allows defining membership both inside and outside the precedence group, but I agree that with terse enough syntax, "outside only" will suffice.</div><div><br></div><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"><div>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.<br></div></div></blockquote><div><br></div><div>This is a highly discussable question. "Outside" option makes it easy to merge standard library operators into a single hierarchy again. Maybe this question can be formulated as follows: should module creator have total control over its operators, or can their behaviour be modified by user?</div><div> </div><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"><div></div><div>This leads the group declaration itself being just of a name and associativity.<br></div><div><br></div><div>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></blockquote><div><br></div><div>I don't think supporting `>` puts much burden on grammar and consistency, but yeah, it gets some points for external precedence.</div><div> </div><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"><div>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.<br></div><div><br></div><div><div>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></blockquote><div><br></div><div>This time the proposal actually reflects these ideas.</div><div><br></div><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"><div>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.<br></div></div></blockquote><div><br></div><div>I have written about creating a separate unnamed group for each operator. That is nonsense, of course, that should be a single named group without associativity.</div><div><br></div><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"><div></div><div><div>Oh wait, Yet another quasi-syntax based on the above:<br></div><div><br></div><div>precedencegroup Additive, associativity: left</div><div>precedencerelation Additive < Multiplicative</div><div>precedencerelation Range < Additive</div><div>infix operator +, group: Additive</div></div></div></blockquote><div><br></div><div>I actually like this syntax (the absence of body, especially), but that commas are inconsistent with the rest of the language. My take at it (hope somebody can do better):</div><div><br></div><div><div>precedencegroup Additive : associativity(left)</div><div>precedencerelation Additive < Multiplicative</div><div>precedencerelation Range < Additive</div><div>infix operator + : Additive</div></div><div> </div><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"><div><span class=""><font color="#888888"><div><br></div><div>-DW</div><div><br></div></font></span><div><div><blockquote type="cite"><div><div class="h5"><div>On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr"><div>The question 4 (<span style="font-size:12.8px">`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><br></div><div>It's not.</div><div>I suggest an alternative syntax for that:</div><div>infix operator <> : Comparative</div><div><br></div><div>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>So, in this scheme, all operators will have no body.</div><div><br></div><div>I also described two methods to declare that operator belongs to a precedence group: in `members` and in operator declaration.</div><div>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><br></div>- Anton</div></div></div><span class="">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>