[erlang-questions] Infix function and user-defined operators

[Dmitry Kolesnikov]

Hello Richard, 

Thank you for valuable feedback.

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.

Current proposal of user defined operator is left associative with same precedence as multiplication. 

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.      


Best Regards,
Dmitry


> On 8 Jan 2019, at 15.53, Richard O'Keefe <raoknz@REDACTED> wrote:
> 
> The Haskell convention for user-defined operators is `name`  .
> I don't see any point in inventing a new one.
> I note that
> (a) http://mlton.org/InfixingOperators <http://mlton.org/InfixingOperators> shows a relatively simple
> scheme for ML that would fit Erlang without too much strain.  It
> starts with a warning that operator properties are not part of
> module interfaces.  This was a problem in Prolog too, and I
> surmise that it may have been the reason for not having user-
> declared operators in Erlang.
> (b) In F#, the type and precedence of a user-defined operator
> are determined by its first character.  See
> 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>
> (c) ECMA Eiffel 8.28.5 puts all unary user-defined operators at the
> same precedence level and all binary user-defined operators at another
> precedence level.  Some other Eiffel dialects followed the same rule as
> F#.  The (b) and (c) rules appear to also be related to not having
> operator properties in signatures/classes/modules/whatever.
> 
> More years ago than I care to admit, I wrote an extended
> Prolog parser that allowed user-defined "operators" like
> "N of L are V" or "at least N of L are V".  It was based
> on Vaughan Pratt's CGOL; see
> https://en.wikipedia.org/wiki/CGOL <https://en.wikipedia.org/wiki/CGOL>
> 
> 
> 
> On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <dmkolesnikov@REDACTED <mailto:dmkolesnikov@REDACTED>> wrote:
> Hello Community,
> 
> 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]. 
> 
> 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. 
> 
> 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.
> 
> ```
> -compile({parse_transform, infix}).
> 
> 1 /plus/ 1.
> 
> F /lists:map/ [1, 2, 3].
> ```
> 
> Right now, I am working on this feature here https://github.com/fogfish/datum/pull/64 <https://github.com/fogfish/datum/pull/64>, you can find more detailed description there, code, etc. 
> 
> I would appreciate for any feedback, suggestion from the community. 
> Does it sounds any usable, still desired or total braindead? 
> What other use-case/applications you might imagine for infix notation?
> 
> Best Regards, 
> Dmitry
>  
> References
> 
> 1. http://erlang.org/pipermail/erlang-questions/2004-March/011929.html <http://erlang.org/pipermail/erlang-questions/2004-March/011929.html>
> 2. https://github.com/fogfish/datum <https://github.com/fogfish/datum> 
> 
> 
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190111/f2c423c4/attachment.htm>