Inline: 2016-04-09 0:17 GMT+03:00 David Waite <[email protected]>:
> Based on commit ‘01317e1a’: > > 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. > 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. 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. > 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? > This leads the group declaration itself being just of a name and > associativity. > > 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. > I don't think supporting `>` puts much burden on grammar and consistency, but yeah, it gets some points for external precedence. > 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. > > 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. > This time the proposal actually reflects these ideas. 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. > 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. Oh wait, Yet another quasi-syntax based on the above: > > precedencegroup Additive, associativity: left > precedencerelation Additive < Multiplicative > precedencerelation Range < Additive > infix operator +, group: Additive > 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): precedencegroup Additive : associativity(left) precedencerelation Additive < Multiplicative precedencerelation Range < Additive infix operator + : Additive > > -DW > > On Apr 8, 2016, at 1:28 PM, Антон Жилин via swift-evolution < > [email protected]> wrote: > > The question 4 (`prefix operator ! { }` or `prefix operator !`) seems > dead simple, because if we need to declare precedence group in body of > infix operators, then other operators should have it for consistency. > > It's not. > I suggest an alternative syntax for that: > infix operator <> : Comparative > > 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. > So, in this scheme, all operators will have no body. > > I also described two methods to declare that operator belongs to a > precedence group: in `members` and in operator declaration. > 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." > > - Anton > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
