[swift-evolution] [Proposal] Custom operators

[Антон Жилин]

In the poposed model, all relations are not transitive. Example:

#precedence(+, lessThan: *)
#precedence(*, lessThan: ^)
1 ^ 2 + 3  // error
#precedence(+, lessThan: ^)
1 ^ 2 + 3  // now ok

Would it be better to have such indirect relations inferred? Or would it
put too much responsibility on the compiler?
Maybe add it to future directions?

Cycles of length >2 are also allowed. This was not added intentionally, but
follows from other specified rules.
Example: ^ (binary) < & (binary) < + < * < ^ (power). OK, & < + is a bit
stretched, otherwise quite logical.

> - I wonder if there are cases in the standard operators which would be
better modeled as a non-linear chain.
In the standard library, non-linearity will be primarily used to break a
single hierarchy into multiple small ones. I doubt that any trees or cycles
will form, although that would be good news.

- Anton

2016-04-04 8:55 GMT+03:00 David Waite <david at alkaline-solutions.com>:

> Interesting model!
>
> If I understand correctly: this changes the precedence from being based on
> a numeric value, to being represented as a bit of a DAG of precedence
> groups. A precedence group is defined implicitly for each operator, with
> one group around each set of operators where equalTo has been declared.
>
> The groups are lazily evaluated, so if an expression can be resolved
> without ambiguity due to lack of reachability between two individual
> operators in the DAG, there is no issue/error.
>
> Comments:
> - I wonder if there are cases in the standard operators which would be
> better modeled as a non-linear chain.  The compiler could warn around usage
> which is defined by operator precedence, but is commonly considered
> ambiguous or error prone.
>
> For example, if users commonly get confused about the conjunctive and
> disjunctive levels (logical ‘and’ and ‘or’) being different levels with
> precedence, you could just omit the lessThan relationship between the two
> of them. The compiler would then error on ambiguous cases, prompting the
> user to use parenthesis.
>
> - I’d prefer instead of operator precedence groups just being implicit by
> use of #precedence equalTo, that the operators are bound to a group
> explicitly. Something like
> #precedence(+, group: “additive”)
> #precedence(“additive”, lessThan: “multiplicative”)
>
> However, this may create more issues than it solves (two frameworks
> creating their own custom operators, putting them in custom precedence
> groups, and the consumer decides the two precedence groups are really
> equivalent)
>
> -DW
>
> On Apr 3, 2016, at 3:36 AM, Антон Жилин via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Swift 2.2 is out, and I restart discussion on syntax for custom operators.
> I insist that this time we should focus less on linguistic aspects.
>
>
> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/64bfd8ae/attachment.html>