[swift-evolution] [Proposal] Custom operators

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

Added
<https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/NNNN-operator-precedence.md#use-precedence-groups>
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?

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).

infix operator Additive {
    members(+, -)
    associativity(left)
}
infix operator Multiplicative {
    members(*, /)
    associativity(left)
    precedence(> Additive)
}

Some other questions:
Do we need transitive precedence propagation?
Do we need resolution of conflicts, i.e. merging multiple definitions of
same operators and groups, where possible?

2016-04-05 22:52 GMT+03:00 Maximilian Hünenberger <m.huenenberger at me.com>:

>
> Am 05.04.2016 um 17:29 schrieb Антон Жилин <antonyzhilin at gmail.com>:
>
> David Waite stated a major drawback of precedence groups.
>
> People will often create tiny precedence groups for their modules, and
> user will find that some of them should actually be the same. They will add
> precedenceEqualTo, but all these equivalent groups will still exist. This
> problem cannot occur with transitive precedence propagation. So precedence
> groups really create more problems than solve.
>
> - Anton
>
>
> Do you mean these drawbacks?
>
> "
>
> 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
>
> "
>
> What is the problem? Changing the relative precedence of external
> operators in your file? Doesn't the same "problem" occur in your proposal
> (only with one operator)?
>
> What is the difference between overriding an operator function like this:
>
> func + (l: Int, r: Int) -> Int {
>        return 0
> }
>
> This can also mess up your code...
> I'm sorry if I haven't understood your point.
>
> From the other email:
>
> I meant, are names `precedenceLessThan`, `precedenceEqualTo` a bit clunky?
> Maybe:
>
> associativity(left)
> precedence(lessThan: +)
> precedence(equalTo: +)
>
> It also solves my concern about dictionary inside braces.
>
>
> I prefer "precedence(+ lessThan *)". However I don't think it's Swift
> style since "lessThan" is like an infix operator *with letters *although
> the symmetry between "+" and "*" would be nicely handled by such operator.
>
> Precedence groups have a great benefit of additional symmetry. Transitive
> precedence propagation, on the other hand, also has benefits:
>
> 1. It does not introduce new entities, just some rules for compiler
> 2. It does not add new keywords. In your current wording, we have to take
> precedence and precedenceGroup as keywords, that's why I
> originally preferred directives
>
>
> Both 1 and 2 are true but I still prefer to use declarations since they
> provide exactly one location where to put operators with equal precedence.
>
> By the way "precedence" is already a keyword... One more to go :)
>
> 3. We actually think in terms of operators, not groups.
> If I want to say that my operator should have the same priority as `+`,
> I'd rather say that I want it to have priority of plus and minus, not
> "belong to multiplicative group".
> If I declare <$> and want it to have same priority as <*>, it would be
> more difficult to invent some name for their group like FunctorManipulator.
>
>
> I think this deserves more discussion:
> Should we allow "precedence(... equalTo ...)" for operators if we have
> precedence groups?
>
> Such a precedence declaration would be contrary to my argument above:
> declare equal operator precedences in one place, which is more maintainable.
>
> On the other hand, in your solution you have a list of global rules
> and don't really need braces. How about this?
>
> #precedenceGroup(Additive)
> #precedenceGroup(Multiplicative)
> #precedence(Additive, less, Multiplicative)
> #operator(+, infix, associativity: left, group: Additive)
> #operator(*, infix, associativity: left, group: Multiplicative)
> #operator(<>, infix)
>
> So precedence group is just a tag that can be used in precedence rules and
> assigned to operators at declaration.
>
>
> Although it is consistent with your proposal for me it is too much
> repetition and "code noise". Compare:
>
> infix operator + { associativity: left }
> infix operator * { associativity: left }
> infix operator <> {}
> precedenceGroup Additive { + }
> precedenceGroup Multiplicative { * }
> precedence(Additive lessThan Multiplicative)
>
> Which is in my opinion way more readable even without syntax highlighting.
>
>
> Thank You for sharing Your thoughts which have enriched me! :)
>
> Best regards
> - Maximilian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/3361d67e/attachment.html>