<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">For what it's worth, Fortran also has user-defined operators, of</div><div class="gmail_default" style="font-family:monospace,monospace">the form /[.][[:alpha:]]+[.]/.  I fear that back in 2004 too many</div><div class="gmail_default" style="font-family:monospace,monospace">people confused *user-defined* *alphabetic* operators with</div><div class="gmail_default" style="font-family:monospace,monospace">*overloaded* or *symbolic* operators, or even user-defined operators</div><div class="gmail_default" style="font-family:monospace,monospace">with user-selected precedence.  (And some forgot that '#!$@' is</div><div class="gmail_default" style="font-family:monospace,monospace">already a perfectly good function name...)</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I recall Bill Clocksin (of "Clocksin & Mellish" Prolog textbook fame)</div><div class="gmail_default" style="font-family:monospace,monospace">saying that if he ever had a chance to redesign Prolog the one thing</div><div class="gmail_default" style="font-family:monospace,monospace">he would improve would be to delete user-defined operators...</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">In a functional language I expect there to be fewer opportunities to</div><div class="gmail_default" style="font-family:monospace,monospace">use prefix or infix operators than in Fortran, because you tend to</div><div class="gmail_default" style="font-family:monospace,monospace">need more arguments.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Speaking of Fortran, that may be why I dislike /foo/ (looks like a</div><div class="gmail_default" style="font-family:monospace,monospace">COMMON block name), and of course in most languages 1/foo/2 would be</div><div class="gmail_default" style="font-family:monospace,monospace">an arithmetic expression with two divisions, which would confuse me.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 11 Jan 2019 at 21:18, 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"><div>Hello Richard, </div><div><br></div><div>Thank you for valuable feedback.</div><div><br></div><div>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><br></div><div>Current proposal of user defined operator is left associative with same precedence as multiplication. </div><div><br></div><div>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><br></div><div><br></div><div>Best Regards,</div><div>Dmitry</div><br><div><br><blockquote type="cite"><div>On 8 Jan 2019, at 15.53, Richard O'Keefe <<a href="mailto:raoknz@gmail.com" target="_blank">raoknz@gmail.com</a>> wrote:</div><br class="gmail-m_-5129359573327694547Apple-interchange-newline"><div><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></blockquote></div><br></div></blockquote></div>