Sorry, "upper" and "lower" was my mistake that I copy-pasted all over the place. Just in case, I added those alternate word variants, as well.
- Anton 2016-05-21 16:31 GMT+03:00 Matthew Johnson <matt...@anandabits.com>: > > > Sent from my iPad > > On May 21, 2016, at 7:48 AM, Антон Жилин <antonyzhi...@gmail.com> wrote: > > Updated the proposal: > > https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md > > I included many of alternate solutions. Please, reply, if I missed any. > > Still I do not hurry to swap any of alternate solution with syntax used > throughout the proposal, although many of them are objectively better. > > > Looks good. I really hope we do go with one of the better syntax forms > though. > > The one thing I don't like is "upper" and "lower". Those don't make sense > to me in this context. Any of < and >, above and below, greaterThan and > lessThan, gt and lt would be better IMO. > > > - Anton > > 2016-05-21 1:17 GMT+03:00 Matthew Johnson <matt...@anandabits.com>: > >> >> On May 20, 2016, at 5:06 PM, Brandon Knope <bkn...@me.com> wrote: >> >> >> >> On May 20, 2016, at 5:56 PM, Антон Жилин via swift-evolution < >> swift-evolution@swift.org> 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 <matt...@anandabits.com>: >> >>> >>> On May 20, 2016, at 4:22 PM, Антон Жилин <antonyzhi...@gmail.com> 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 <matt...@anandabits.com>: >>> >>>> >>>> On May 20, 2016, at 3:51 PM, John McCall <rjmcc...@apple.com> wrote: >>>> >>>> On May 20, 2016, at 1:25 PM, Антон Жилин <antonyzhi...@gmail.com> >>>> wrote: >>>> Inline: >>>> >>>> 2016-05-20 20:58 GMT+03:00 John McCall <rjmcc...@apple.com>: >>>> >>>>> 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
