Sent from my iPad
> On May 21, 2016, at 7:48 AM, Антон Жилин <[email protected]> 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 <[email protected]>: >> >>> 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]> 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]>: >>>>> >>>>>> On May 20, 2016, at 4:22 PM, Антон Жилин <[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]>: >>>>>>> >>>>>>>>> On May 20, 2016, at 3:51 PM, John McCall <[email protected]> wrote: >>>>>>>>> >>>>>>>>> On May 20, 2016, at 1:25 PM, Антон Жилин <[email protected]> >>>>>>>>> wrote: >>>>>>>>> Inline: >>>>>>>>> >>>>>>>>> 2016-05-20 20:58 GMT+03:00 John McCall <[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] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
