General discussions: Defining a custom infix function aka operator

oezguery 2023-12-15 00:30:29

Dear Forum,
I have not been able to solve new puzzles but I am continuing to learn new concepts, expecially in functional programming. I am trying to learn F# and today it made me very happy because I finally discovered a way of doing something that I always wanted to do; creating my own custom operator.

Some of you may be already aware of it but I am sure it is entirely unknown to the majority of programmers that one can create a custom operator. Well, it is possible and F# lets you do it. Give it a try, you won't regret it.

One example:

let distance x y = if x<y then y-x else x-y     // val distance: int -> int -> int
let (|><|) x y = distance x y                   // val (|><|): int -> int -> int
9 |><| 3                                        // val it: int = 6
9 |><| 3 |><| 10                                // val it: int = 4

ecolog_veteran 2023-12-15 06:29:03

It is cool, I agree, but from what I know, creating custom operators (not overloading them) is only possible in Haskell, F#, and probably other functional languages.

C++, for instance, only lets a programmer overload already existing operators, like arithmetic ones.

I may be missing something here, though.

Rodion (admin) 2023-12-15 07:27:19

Hi Özgür, glad to hear from you - and it's curious you are trying such radical things like F# - I personally heard of it only once at internal knowledge sharing in some company 10 years ago. However the aspiration about functional programming somewhat dissipated since then (people suddenly found the world is not functional, ha-ha) so I hadn't much motivation to review it...

I completely agree that the feature of creating custom operators is cool on itself - especially when we learn and compare different languages out of curiosity. However I suspect in practical projects there is not much motivation to create whimsical operators. Even redefinition, which was popularized by C++ (and exists even in Lua) doesn't seem appealing to programmers. I guess I know why.

Nowadays programs become somewhat complicated and large, and we generally try to give various functions and subroutines names which are self-documenting, i.e. the code is less or more readable without comments.

Trying to code with operators, especially fancy ones, instead of human-readable names, is opposite to this idea. In theory this may be useful in some libraries (e.g. dealing with matrices or some other math objects etc) - in practice even this motivation is somewhat weak.

If you had a chance to examine the language called APL you may easily get the idea what happens when graphical operators are used for almost every action. Though probably nowadays few people remember it - it required special printing machin which can type over existing symbols on paper - and this faded out in the era of text-only cathode ray terminals.

Anyway, of course, this shouldn't discourage us from experimenting and even creating new languages. The matter is that we, programmers, use and create languages not only for practical tasks, but also for our own amusement :)))

P.S. sample of the program in APL - it's normal line-oriented text, just using bit too many various symbols

APL program example

qwerty 2023-12-15 11:00:06

sample of the program in APL

I feel like I should take this language for next code golf championship...

oezguery 2023-12-15 12:39:34

In theory custom operators are cool. Imagine a domain like dating service. There are Person objects. We can define :heart: (emoji) operator which works like this

relation = person1 :heart: person2

qwerty 2023-12-15 14:20:50

And we can describe love triangle as:

triangle = person1 :heart: person2 :heart: person3

person1 wants to date with person2, but person2 wants to date with person3.

When dating service sees such expression, it probably must compare relationships and choose most promising one.