Inline
> Am 04.04.2016 um 08:06 schrieb Антон Жилин <[email protected]>:
>
> Thank you for a helpful answer!
> I like the idea of overriding precedence from another module. We won't need
> to introduce additional keywords or visibility for operators. I will add it
> to the proposal.
>
> I assume you mean precedence inside braces of operator, then operator scope
> makes sense. Self operator could be omit as well, following the idea that we
> are introducing a new operator and want to compare it to others:
>
> infix operator * {
> associativity: left
> precedenceLess: ^
> precedenceEqual: /
> precedenceGreater: +
> }
> infix operator / {
> associativity: left
> precedenceLess: ^
> precedenceEqual: *
> precedenceGreater: +
> }
>
> Equivalent precedence rules would be allowed for symmetry in the operator
> definitions.
> We would still be able to reopen the scope and add precedence and
> associativity rules.
> I agree that this scheme has advantage of being a smaller change.
>
> I'm still concerned about syntax.
> Is it OK to have "less, equal, greater" in precedence name?
What do you mean by OK? Other operators like == are weird:
precedence(== == <)
// in comparison to
precedence(== equalTo <)
> Is it OK to have both curly brackets and dictionary syntax (a precedent, I
> guess)?
That could be a consistency problem. However I'd like to keep a declaration
syntax instead of defining operators through compiler directives.
> Is it OK to leave prefix and postfix operators always with empty braces?
>
I'm fine with that.
> Would it be better to have multiple precedence comparisons at once:
> precedenceGreater: +, -, *, /
> Or one comparison per line will be more readable?
>
> I will add this to alternatives, but will not swap it with currently stated
> syntax for now, waiting for some more response.
>
> What do you think?
>
> - Anton
After thinking more about it I came to the conclusion that we should have
something like "precedence groups" where all operators have the same precedence:
precedenceGroup Additive {
+, -
}
precedenceGroup Multiplicative {
*, /
}
// first we could allow an operator to be only
// in one p.Group. Later when we can infer
// precedences we can allow operators to be
// in more than one p.Group (if that is even necessary)
// precedence declaration
precedence(Additive lessThan Multiplicative)
// precedence declarations take
// "precedenceGroup"s and "operator"s.
// It could also work with extensions so you
// can easily insert it in the precedence hierarchy:
infix operator +- {
associativity: left
}
// more operator declarations ...
extension Additive {
+-, -+, ++, --
}
// the syntax I used is highly discussable.
// this should mainly be a concept suggestion.
// I think it allows for greater flexibility since you can define
// operator precedences much easier.
With kind regards
- Maximilian
>
> 2016-04-04 8:06 GMT+03:00 Maximilian Hünenberger <[email protected]>:
>> See inline
>>
>>> Am 03.04.2016 um 13:26 schrieb Ross O'Brien via swift-evolution
>>> <[email protected]>:
>>>
>>> There is a problem here of duplicated operators or custom precedence, and
>>> how that gets passed between modules.
>>> Assume there are three modules, A, B and C. B defines a custom operator **.
>>> A and C each define a custom operator ++, and their meanings are different
>>> (though, even if their meanings were the same, I'm not sure if they could
>>> unify).
>>>
>>> Module D uses A and B as dependencies and sets a custom precedence on ++
>>> and **. Module E uses B and C and has a different precedence on ++ and **.
>>> You're working on Module F which uses D and E. Which ++ and which
>>> precedence does F get implicitly?
>>>
>>
>> We could allow operator precedence overriding to resolve ambiguity. However
>> this overriding should only be module internal since it would override the
>> existing precedences in the other modules.
>>
>> @AHTOH
>> Why do you use #keyword ?
>> I think defining a operator with
>>
>> infix operator + {
>> associativity: left
>> }
>>
>> is perfectly fine since it is similar to class/struct/enum declaration.
>>
>> // and it's precedence
>> precedence(+ lessThan *)
>>
>> Note the missing "," and ":" before and after "lessThan" in order to give
>> both operators the same importance (minor issue).
>>
>> I feel that
>>
>> #precedence(+, lessThan: *)
>>
>> puts too much importance on the first operator.
>>
>> Best regards
>> - Maximilian
>>> _______________________________________________
>>> 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
