<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">The Haskell convention for user-defined operators is `name` .</div><div class="gmail_default" style="font-family:monospace,monospace">I don't see any point in inventing a new one.</div><div class="gmail_default" style="font-family:monospace,monospace">I note that</div><div class="gmail_default" style="font-family:monospace,monospace">(a) <a href="http://mlton.org/InfixingOperators">http://mlton.org/InfixingOperators</a> shows a relatively simple</div><div class="gmail_default" style="font-family:monospace,monospace">scheme for ML that would fit Erlang without too much strain. It</div><div class="gmail_default" style="font-family:monospace,monospace">starts with a warning that operator properties are not part of</div><div class="gmail_default" style="font-family:monospace,monospace">module interfaces. This was a problem in Prolog too, and I</div><div class="gmail_default" style="font-family:monospace,monospace">surmise that it may have been the reason for not having user-</div><div class="gmail_default" style="font-family:monospace,monospace">declared operators in Erlang.</div><div class="gmail_default" style="font-family:monospace,monospace">(b) In F#, the type and precedence of a user-defined operator</div><div class="gmail_default" style="font-family:monospace,monospace">are determined by its first character. See</div><div class="gmail_default"><font face="monospace, monospace"><a href="https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/index">https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/index</a></font><br></div><div class="gmail_default"><font face="monospace, monospace">(c) ECMA Eiffel 8.28.5 puts all unary user-defined operators at the</font></div><div class="gmail_default"><font face="monospace, monospace">same precedence level and all binary user-defined operators at another</font></div><div class="gmail_default"><font face="monospace, monospace">precedence level. Some other Eiffel dialects followed the same rule as</font></div><div class="gmail_default"><font face="monospace, monospace">F#. The (b) and (c) rules appear to also be related to not having</font></div><div class="gmail_default"><font face="monospace, monospace">operator properties in signatures/classes/modules/whatever.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">More years ago than I care to admit, I wrote an extended</font></div><div class="gmail_default"><font face="monospace, monospace">Prolog parser that allowed user-defined "operators" like</font></div><div class="gmail_default"><font face="monospace, monospace">"N of L are V" or "at least N of L are V". It was based</font></div><div class="gmail_default"><font face="monospace, monospace">on Vaughan Pratt's CGOL; see</font></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://en.wikipedia.org/wiki/CGOL">https://en.wikipedia.org/wiki/CGOL</a><br></font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <<a href="mailto:dmkolesnikov@gmail.com">dmkolesnikov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hello Community,<div><br></div><div>Now and then, I am missing an infix notation in Erlang. There was a great discussion about this subject decade and half ago but I do not think anything is changed [1]. </div><div><br></div><div>I am testing and stretching limits of functional abstracts in Erlang as part of my pure functional and generic programming exercises [2]. I’ve decided to experiment with Infix function via parse-transform. </div><div><br></div><div>The parse_transform feature implements a syntax sugar for infix, which is compiled into valid Erlang code using corresponding function at compile-time. To apply a function using infix notation, we enclose its name in slash characters (/). This allows us to use any arity 2 functions as infix operators.<br><br>```<br>-compile({parse_transform, infix}).<div><br></div>1 /plus/ 1.<div><br></div>F /lists:map/ [1, 2, 3].</div><div>```</div><div><br></div><div>Right now, I am working on this feature here <a href="https://github.com/fogfish/datum/pull/64" target="_blank">https://github.com/fogfish/datum/pull/64</a>, you can find more detailed description there, code, etc. </div><div><br></div><div>I would appreciate for any feedback, suggestion from the community. </div><div>Does it sounds any usable, still desired or total braindead? </div><div>What other use-case/applications you might imagine for infix notation?</div><div><br></div><div>Best Regards, </div><div>Dmitry</div><div> </div><div>References</div><div><br></div><div>1. <a href="http://erlang.org/pipermail/erlang-questions/2004-March/011929.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2004-March/011929.html</a></div><div>2. <a href="https://github.com/fogfish/datum" target="_blank">https://github.com/fogfish/datum</a> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>