> On May 20, 2016, at 5:06 PM, Brandon Knope <[email protected]> wrote: > > > > On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> My working version is still the one in the proposal, but I'm planning to add >> the alternative versions we discussed, including your and Brent's variants. >> >> IMHO, original version is heavy, but clear (not to confuse with "clean"). >> Your lighter version looks more clean, but somewhat less consistent and more >> free in terms of grammar. >> >> Also, I've got another version, which is considerably ligher than current >> one, while being as structured: >> >> precedence Multiplicative { >> associativity(left) >> above(Additive) >> below(Exponentiative) >> } > > Why not: > > precedence Multiplicative { > associativity left > above Additive > below Epxonentiative > } > > Just seeing if removing the parens reduces some of the noise.
I would be happy with this. It is almost the same as what I had suggested, just using > and < rather than above and below (because that was what the proposal was using). Using words instead is fine with me. The parens are my biggest objection in this version. In the original version I also didn’t like the verbosity of `precedencegroup` and the redundant statement `precedence` inside the braces. > > Sorry if I missed this suggestion earlier and it was denied :P > > Brandon > > > >> >> - Anton >> >> 2016-05-21 0:25 GMT+03:00 Matthew Johnson <[email protected] >> <mailto:[email protected]>>: >> >>> On May 20, 2016, at 4:22 PM, Антон Жилин <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Yes, in this case it should be allowed, because this relationship already >>> existed in imported modules. I will add that, too, thanks! >> >> Cool. >> >> What is the latest syntax you are using? Did you consider any of the >> lighter weight options? That subthread died without conclusion (unless I >> missed something somehow). >> >> >>> >>> - Anton >>> >>> 2016-05-21 0:01 GMT+03:00 Matthew Johnson <[email protected] >>> <mailto:[email protected]>>: >>> >>>> On May 20, 2016, at 3:51 PM, John McCall <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> On May 20, 2016, at 1:25 PM, Антон Жилин <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> Inline: >>>>> >>>>> 2016-05-20 20:58 GMT+03:00 John McCall <[email protected] >>>>> <mailto:[email protected]>>: >>>>> The transitivity rule plus the ability to define precedence relationships >>>>> in both directions on a new precedence group allows a new precedence >>>>> group to create a precedence relationship between existing unrelated >>>>> precedence groups. This should be forbidden. >>>>> >>>>> Agreed, although there is an alternate solution to allow global-scope >>>>> relationship definition. >>>>> Trying to write it formally: >>>>> >>>>> ====begin==== >>>>> Precedence relationships that, by transitivity rule, create relationship >>>>> between two imported groups, is an error. Example: >>>>> >>>>> // Module X >>>>> precedencegroup A { } >>>>> precedencegroup C { } >>>>> >>>>> // Module Y >>>>> import X >>>>> precedencegroup B { precedence(> A) precedence(< C) } >>>>> >>>>> This results in compilation error "B uses transitivity to define >>>>> relationship between imported groups A and C". >>>>> The rationale behind this is that otherwise one can create relationships >>>>> between standard precedence groups that are confusing for the reader. >>>>> ====end==== >>>> >>>> Seems good to me. >>> >>> Would this be allowed if Module X already defined precedence group C > A >>> (it would not be defining a *new* relationship between A and C in that >>> case)? >>> >>>> >>>>> What's the purpose of equality relationships between precedence groups? >>>>> >>>>> Agreed, will remove. >>>> >>>> Ok. >>>> >>>>> Your proposal should call out the special treatment of the Assignment and >>>>> Ternary groups. >>>>> >>>>> Do you mean that most operators should define greater precedence than >>>>> Assignment / Ternary? Or there should be some other special treatment? >>>> >>>> Just that they have implicit members. >>>> >>>> John. >>> >>> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
