[swift-evolution] [Draft] Resolving operator precedence conflicts

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

TLDR: Previous draft did not carry the idea well, I will rewrite it.

In my original post, I didn't intend to make an accent on syntax. I mainly
tried to rework how operator precedence works.

Consider following example.
Module A defines operator |> that acts on Stream, is left-associative and
has precedence rules X.
Module B defines operator |> that acts on Serializable, is
right-associative and has precedence rules Y.

A and B don't know anything about each other.
Without the proposal, definitions of |> would be in conflict.
With the proposal, there would be no conflict for |>. They would
define different operators with different precedence rules and
associativity.

In expression a + b + c, first and second + would have different precedence
and associativity, depending on #operator directives, types of a,b,c and
available perator functions.

Now I think that probably, having conflicts in operator definitions is
better than to have complex compiler rules for parsing expressions as
simple as a + b + c.

- Anton

четверг, 10 марта 2016 г. пользователь Chris Lattner написал:

>
> > On Mar 9, 2016, at 11:15 AM, Sean Heber via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >
> > Isn’t this essentially describing it’s expression-ness? Why not just use
> “expression” like:
> >
> > expression: infix
> > expression: postfix
> > expression: prefix
>
> Are any of these proposals *better* than “infix operator + {“ ?
>
> I’m not claiming that the body of the operator declaration is great, but
> one nice thing about it is that the required terms are part of the decl
> modifier, the optional gunk is in the body, and it reads well.
>
> -Chris
>
>
> >
> > l8r
> > Sean
> >
> >
> >> On Mar 9, 2016, at 1:12 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >>
> >>
> >>> On Mar 9, 2016, at 12:10 PM, Charles Kissinger <crk at akkyra.com
> <javascript:;>> wrote:
> >>>
> >>>
> >>>> On Mar 8, 2016, at 1:52 PM, Austin Zheng <austinzheng at gmail.com
> <javascript:;>> wrote:
> >>>>
> >>>> 'Fixity' already has a non-technical meaning ("the state of being
> unchanged and permanent"), and an unrelated technical one (a synonym for
> associativity; search "assocativity fixity operator" for examples). If
> we're using it in this different way, I respectfully submit that we should
> reconsider.
> >>>
> >>> You are correct, of course, but a subset of computer scientists have
> been abusing the term in this way for at least a couple of decades. Their
> novel usage of “fixity” now has a degree of fixity, so it may be too late
> to fix "fixity".
> >>
> >> It's become a termity of art.
> >>
> >> -- E
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org <javascript:;>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160310/82ecdc0a/attachment.html>