<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hello Richard, </div><div class=""><br class=""></div><div class="">Thank you for valuable feedback.</div><div class=""><br class=""></div><div class="">Indeed `name` is the best option. However, it requires changes to the compiler. Unfortunately, it do not have any visibility why this feature has been rejected 14 years ago. I found that /name/ is the closed approximation of Haskell’s `name` achievable with core Erlang syntax thus implementable via parse transforms.</div><div class=""><br class=""></div><div class="">Current proposal of user defined operator is left associative with same precedence as multiplication. </div><div class=""><br class=""></div><div class="">I also thought about /f> and <f/ similarly to MLton but have not build a final conclusion yet. The “single” character operators can be achieved via /$_/ with some limitation. One of the problem here is name of module to conduct its implementation. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Best Regards,</div><div class="">Dmitry</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 8 Jan 2019, at 15.53, Richard O'Keefe <<a href="mailto:raoknz@gmail.com" class="">raoknz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><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" class="">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" class=""><a href="https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/index" class="">https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/index</a></font><br class=""></div><div class="gmail_default"><font face="monospace, monospace" class="">(c) ECMA Eiffel 8.28.5 puts all unary user-defined operators at the</font></div><div class="gmail_default"><font face="monospace, monospace" class="">same precedence level and all binary user-defined operators at another</font></div><div class="gmail_default"><font face="monospace, monospace" class="">precedence level. Some other Eiffel dialects followed the same rule as</font></div><div class="gmail_default"><font face="monospace, monospace" class="">F#. The (b) and (c) rules appear to also be related to not having</font></div><div class="gmail_default"><font face="monospace, monospace" class="">operator properties in signatures/classes/modules/whatever.</font></div><div class="gmail_default"><font face="monospace, monospace" class=""><br class=""></font></div><div class="gmail_default"><font face="monospace, monospace" class="">More years ago than I care to admit, I wrote an extended</font></div><div class="gmail_default"><font face="monospace, monospace" class="">Prolog parser that allowed user-defined "operators" like</font></div><div class="gmail_default"><font face="monospace, monospace" class="">"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" class="">on Vaughan Pratt's CGOL; see</font></div><div class="gmail_default"><font face="monospace, monospace" class=""><a href="https://en.wikipedia.org/wiki/CGOL" class="">https://en.wikipedia.org/wiki/CGOL</a><br class=""></font></div><div class="gmail_default"><font face="monospace, monospace" class=""><br class=""></font></div><div class="gmail_default"><br class=""></div></div></div></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <<a href="mailto:dmkolesnikov@gmail.com" class="">dmkolesnikov@gmail.com</a>> wrote:<br class=""></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" class="">Hello Community,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class="">```<br class="">-compile({parse_transform, infix}).<div class=""><br class=""></div>1 /plus/ 1.<div class=""><br class=""></div>F /lists:map/ [1, 2, 3].</div><div class="">```</div><div class=""><br class=""></div><div class="">Right now, I am working on this feature here <a href="https://github.com/fogfish/datum/pull/64" target="_blank" class="">https://github.com/fogfish/datum/pull/64</a>, you can find more detailed description there, code, etc. </div><div class=""><br class=""></div><div class="">I would appreciate for any feedback, suggestion from the community. </div><div class="">Does it sounds any usable, still desired or total braindead? </div><div class="">What other use-case/applications you might imagine for infix notation?</div><div class=""><br class=""></div><div class="">Best Regards, </div><div class="">Dmitry</div><div class=""> </div><div class="">References</div><div class=""><br class=""></div><div class="">1. <a href="http://erlang.org/pipermail/erlang-questions/2004-March/011929.html" target="_blank" class="">http://erlang.org/pipermail/erlang-questions/2004-March/011929.html</a></div><div class="">2. <a href="https://github.com/fogfish/datum" target="_blank" class="">https://github.com/fogfish/datum</a> </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>_______________________________________________<br class="">
erlang-questions mailing list<br class="">
<a href="mailto:erlang-questions@erlang.org" target="_blank" class="">erlang-questions@erlang.org</a><br class="">
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank" class="">http://erlang.org/mailman/listinfo/erlang-questions</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>