> Am 05.04.2016 um 22:32 schrieb Антон Жилин <[email protected]>:
>
> Added group version, "lessThan" problem can be solved nicely. `<`, `=`, `>`
> signs would be allowed there.
>
> > Should we allow "precedence(... equalTo ...)" for operators if we have
> > precedence groups?
> I think no.
>
> I have a question to your group syntax.
> Since all operators in a precedence group must have equal associativity for
> parsing to work and look logically (right?), wouldn't it be better to declare
> associativity in groups?
> If so, then body of operator declaration won't contain anything, and we can
> remove it:
>
> precedenceGroup Additive {
> associativity(left)
> +, -
> }
> infix operator +
> infix operator -
>
> Does this body of precedenceGroup look OK from syntactic PoV?
Associativity in precedence groups is fine however the operators should then be
grouped possibly: "operators(+, -)"
>
> Now, I have another idea.
> As operator declarations themselves don't contain anything anymore, remove
> operator declarations at all. We don't need to pre-declare function names,
> for example.
> Next, `precedenceGroup` could be as well replaced with `precedenceLevel`, or
> just `precedence`, and I would not worry about additional keywords.
> So, our example would look like this:
>
> precedence Additive {
> associativity(left)
> +, -
> }
> precedence Multiplicative {
> associativity(left)
> *, /
> }
> precedence(Additive < Multiplicative)
>
> As a future direction, we could add extensions to precedence levels.
> We could go further and replace `precedence` with `operator`, abandoning the
> idea of priority for prefix and postfix operators (that I honestly don't
> like).
Regarding pre- and postfix operators: there was a separate thread which
discussed exactly this. The biggest problem was that if a prefix "-" has lower
precedence than an infix operator like "^" this calculation is ambiguous from a
human perspective:
-3 ^ 3
"-" has visually the higher precedence and the result would be 9. However the
actual result is -9.
If we have precedence on pre- and postfix operators we would break existing
code. A migratory could then enforce the old precedence levels with braces. But
then we can resolve existing (visual) ambiguities and "mathematical
incorrectness" by making the precedence of prefix "-" higher than the current
comparative operators and not declare its precedence to higher precedence
operators (precedence > 140)
Such that this expression is ambiguous to the compiler:
3 - -3 // also mathematically incorrect
// and should be rewritten to
3 - (-3)
// or just
3 + 3
> infix operator Additive {
> members(+, -)
> associativity(left)
> }
> infix operator Multiplicative {
> members(*, /)
> associativity(left)
> precedence(> Additive)
> }
>
> Some other questions:
> Do we need transitive precedence propagation?
Yes because it would be quite a pain to declare every precedence between all
precedence groups:
#needed precedence declarations ~ O(#of precedence groups ^ 2)
> Do we need resolution of conflicts, i.e. merging multiple definitions of same
> operators and groups, where possible?
>
I think we shouldn't define operators in a precedence group because if we want
to have an operator in two different groups then we have two operator
definitions which can result in a conflict.
I'm not sure if we need the same operator in different groups. Therefore I'd
suggest to declare all standard library operators in this form in order to see
if we need this.
So my current syntax suggestion is:
infix operator + { associativity(left) }
prefix operator -
infix operator && { associativity(left) }
infix precedenceGroup Additive {
associativity(left)
members(+)
}
infix precedenceGroup Logical {
associativity(left)
members(&&)
}
prefix precedenceGroup Sign {
members(-)
}
precedence(Additive > Logical)
precedence(Sign > Logical)
// warning: duplicate precedence declarations
precedence(Logical < Additive)
--------
I declare associativity in operator declarations and precedence group
declarations since it lets the compiler check whether the "members" have the
right associativity.
Best regards
- Maximilian _______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
