Infix function and user-defined operators

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Infix function and user-defined operators

Dmitry Kolesnikov-2
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, 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







_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

Richard O'Keefe
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 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
(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



On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <[hidden email]> 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, 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






_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

Dmitry Kolesnikov-2
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 <[hidden email]> 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 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
(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



On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <[hidden email]> 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, 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






_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

Richard O'Keefe
For what it's worth, Fortran also has user-defined operators, of
the form /[.][[:alpha:]]+[.]/.  I fear that back in 2004 too many
people confused *user-defined* *alphabetic* operators with
*overloaded* or *symbolic* operators, or even user-defined operators
with user-selected precedence.  (And some forgot that '#!$@' is
already a perfectly good function name...)

I recall Bill Clocksin (of "Clocksin & Mellish" Prolog textbook fame)
saying that if he ever had a chance to redesign Prolog the one thing
he would improve would be to delete user-defined operators...

In a functional language I expect there to be fewer opportunities to
use prefix or infix operators than in Fortran, because you tend to
need more arguments.

Speaking of Fortran, that may be why I dislike /foo/ (looks like a
COMMON block name), and of course in most languages 1/foo/2 would be
an arithmetic expression with two divisions, which would confuse me.


On Fri, 11 Jan 2019 at 21:18, Dmitry Kolesnikov <[hidden email]> wrote:
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 <[hidden email]> 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 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
(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



On Tue, 8 Jan 2019 at 04:56, Dmitry Kolesnikov <[hidden email]> 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, 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






_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

empro2

> >> I would appreciate for any feedback, suggestion from
> >> the community. Does it sounds any usable, still
> >> desired or total braindead?

I distantly recall C++-people fear the inventiveness of
programmers in (ab-?)using 'operator' ...


> >> What other
> >> use-case/applications you might imagine for infix
> >> notation?

Does infix-notation carry any inherent superiority apart
from people being used to infix-expressions? And: is that
set of expressions not more or less small and limited to
what they have learned in school, at college, ...?

I am (so far) missing only infix "B^E". Would unary-prefix
"ln A" and "e^A" mostly be used with a bracketed argument
anyway? would these be some real improvement compared
to log(A) and exp(A) ...?

Perhaps some 'in_module M' could clean away "math:" clutter
in calculations ... but I am drifting off topic ...

Michael

--

That which was said, is not that which was spoken,
but that which was understood; and none of these
comes necessarily close to that which was meant.










_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

Mikael Pettersson-5
On Wed, Jan 16, 2019 at 8:46 PM <[hidden email]> wrote:
> > >> What other
> > >> use-case/applications you might imagine for infix
> > >> notation?
>
> Does infix-notation carry any inherent superiority apart
> from people being used to infix-expressions?

Ah, this is the rub.

As an old-time LISP and Scheme aficionado, I find this obsession with
infix notation weird.  The generic function call syntax, whether you
prefer f(X, Y) or (f X Y), is unambiguous and more flexible since it
allows different arities.

Infix operators are tolerable when they're few and fixed by the
language.  Add user-defined ones, overloading, user-defined precedence
and associativity, and you get a recipe for unreadable code.  No
thanks.

About the only use for non-prefix notation I can find is for compound
literals, where it's useful to be able to say e.g. [X, Y | Z] in
_both_ pattern-matching and expression evaluation contexts.  (One
thing I think LISP got wrong is that the syntax for a compound literal
wasn't also the syntax for an expression evaluating to that literal.
But I digress.)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

Richard O'Keefe
In reply to this post by empro2
It's ironic that you mention C++, because C++ is *the* example of
operator abuse.  I mean, *really*, using "<<" for both left shift
and output?  That's almost as evil as using "+" for string concatenation.
The problem with C++ is that it allows completely ad hoc overloading
BUT does not allow operator *introduction* so that there is enormous
pressure on the same few operators that happen to be built in.

The example of X^Y is an interesting one, because you don't, you really
don't, want to go around writing exp(Y*log(X)) all the time.  Not only
does it involve three operations, when only one is intended, but in
many cases they are the *wrong* operations.  (Notably, but not only,
when Y is an integer.)  The other thing is the notation itself.  There
is no such operator in high-school maths.  And the reason ^ is used is
that in ASCII-63 (as implemented on the Model 33 teletype, for one
popular example), that codepoint was used for ↑ so people were actually
writing X↑Y.  ASCII-67 replaced ↑ with ^.  And there were two operators
ASCII meant to give us that we seldom get.  The \ character was added
to ASCII for the specific purpose of letting you write /\ (and, min,
meet) and \/ (or, max, join).  How many programming languages let you
use _those_ very well established operators?

There are many things that might reasonably be taken as infix
operators:
   List includes Element
   Long begins_with Short
   X <=> Y                 -- increasingly popular 3-way comparison
(these examples were chosen to be at the same level as >=)
   Mat1 %*% Mat2           -- matrix multiplication in R
   Set1 union: Set2        -- set operation in Smalltalk
and of course assorted parser combinators and other combinators.
I count 28 operators in SML.  (Proper handling of IEEE comparison
needs more than six "relational operators", and SML has some but
not all of the extras.)

Here's an interesting question.
The designers of Ada thought that letting people mix up 'and' and 'or'
without parentheses was dangerous.  So you can have
   e0 and e1 and ... and en
and you can have
   e0 or e1 or ... or en
but you cannot have
   e0 and e1 or e2
So are 'and' and 'or' operators in Ada, or should they be thought of as
special multi-operator forms?  If the latter, how would you declare such things?

My own impression, and it is no more than that,
is that infix operators help a lot when you are treating something
as a quasi-algebraic expression that you are interested in rearranging
and simplifying in a mathematical way.  I don't think it is a coincidence
that the Bird-Meertens approach does that, and that specification languages
often have lots of operators.  In particular, when you are transforming
expressions by hand, you can tolerate a fair bit of precedence fuzziness
and even outright ambiguity.
On the other hand, bulkier, clunkier, but more obvious syntax seems to
work better for code that you want other people to read.

Just an impression, for what it is worth.







_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Infix function and user-defined operators

empro2
> It's ironic that you mention C++, because C++ is *the*
> example of operator abuse.

Ironic? That is the reason why I mentioned it. I put the
"ab-" in brackets because I am too stupid to get anywhere
near a licence to mention naked mole rats.


> The example of X^Y is an interesting one, because you
> don't, you really don't, want to go around writing
> exp(Y*log(X)) all the time.

math:pow(X, Y)? (Sorry, if I am being stupid.)

Speaking of it: I do not understand why there is no
math:log/2 ... but, lest there be any misunderstanding, I
do not want it as an infix fun! (or should I?)


> My own impression, and it is no more than that,
> is that infix operators help a lot when you are treating
> something as a quasi-algebraic expression that you are
> interested in rearranging and simplifying in a
> mathematical way.

But is that the operators in themselves or the being used to
them? Are there Lispers who do not have to "translate"
between "common" algebraic and Lisp phrasings (like I have
to)? or who even rearrange and simplify s-exps more easily
than ...?

To reverse the poles (how punny): some Forth people claim
that understanding Forth is an enlightening experience ...
(then again, sawing off ones foot might also be ;-)

When this thread came up, one of my first thoughts was:
why not stop _teaching_ any infix notation at all and
forget all these lexically invisible precedence and
associativeness rules? (I mitigated this heresy to that
question about "inherent superiority".)


> and even outright ambiguity. On the other hand, bulkier,
> clunkier, but more obvious syntax seems to work better
> for code that you want other people to read.

That could explain why coding style guides often suggest or
demand use of brackets instead of relying on operator rules.

--

“Even after a thousand explanations a fool is no wiser,
whereas someone intelligent requires only one fourth of
these.”

        – from the Mahābhārata (महाभारत)







_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions