<div><font size="2"><span style="background-color:rgba(255,255,255,0)">TLDR: Previous draft did not carry the idea well, I will rewrite it.</span></font></div><font size="2"><span style="background-color:rgba(255,255,255,0)"><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div>In my original post, I didn't intend to make an accent on syntax. I mainly tried to rework how operator precedence works.</span></font><div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);"><br></span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Consider following example.</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Module A defines operator |> that acts on Stream, is left-associative and has precedence rules X.</span></font></div><div><font size="2"><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.301961);">Module B defines operator |> that acts on</span></font><span style="font-size:small"> Serializable, is right-associative and has precedence rules Y.</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">A and B don't know anything about each other.</span></div><div><span style="font-size:small">Without the proposal, definitions of |> would be in conflict.</span></div><div><span style="font-size:small">With the proposal, there would be no conflict for |>. They would define different operators with different precedence rules and associativity.</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">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.</span></div><div><span style="font-size:small"><br></span></div><div><span style="font-size:small">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.</span></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"></span></font><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">- Anton</span></font></div><br>четверг, 10 марта 2016 г. пользователь Chris Lattner написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 9, 2016, at 11:15 AM, Sean Heber via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Isn’t this essentially describing it’s expression-ness? Why not just use “expression” like:<br>
><br>
> expression: infix<br>
> expression: postfix<br>
> expression: prefix<br>
<br>
Are any of these proposals *better* than “infix operator + {“ ?<br>
<br>
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.<br>
<br>
-Chris<br>
<br>
<br>
><br>
> l8r<br>
> Sean<br>
><br>
><br>
>> On Mar 9, 2016, at 1:12 PM, Erica Sadun via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On Mar 9, 2016, at 12:10 PM, Charles Kissinger <<a href="javascript:;" onclick="_e(event, 'cvml', 'crk@akkyra.com')">crk@akkyra.com</a>> wrote:<br>
>>><br>
>>><br>
>>>> On Mar 8, 2016, at 1:52 PM, Austin Zheng <<a href="javascript:;" onclick="_e(event, 'cvml', 'austinzheng@gmail.com')">austinzheng@gmail.com</a>> wrote:<br>
>>>><br>
>>>> '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.<br>
>>><br>
>>> 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".<br>
>><br>
>> It's become a termity of art.<br>
>><br>
>> -- E<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote></div></div>