Support for Unicode Mathematical Symbols (∪, ∩, ∈) as Infix Operators in F#

[allan-mattos]

Currently, the F# compiler does not allow Unicode mathematical symbols to be used as infix operators. This limits expressiveness and productivity both at the high school level and in professional work, as well as in academic scenarios, especially in set theory.

Proposal: Allow symbols such as ∪, ∩, ∈ to be recognized as infix operators, just like +, -, *.

Expected Impact:
1)Anyone who completed high school would feel more attracted to programming.

2)Unification between Mathematics and Programming Language.

3)Simplicity in code writing and reading.

4)Faster writing .

5)Expansion of the F# language itself, making it more expressive and accessible.

Example:

fsharp
// Today
let C = Set.union A B
let D = Set.intersect A B
let ok = Set.contains 3 A

// Proposed
let inline ( ∪ ) A B = Set.union A B
let inline ( ∩ ) a b = Set.intersect a b
let inline ( ∈ ) x set = Set.contains x set

let C = A ∪ B
let D = A ∩ B
let ok = 3 ∈ A
This change could bring mathematics even closer to programming and open doors to new audiences.

[allan-mattos]

I’d love to hear the community’s thoughts on this proposal.

Do you see value in allowing Unicode mathematical symbols as infix operators?

What other symbols would you consider essential for mathematical or scientific programming?

Are there technical challenges or parsing concerns that you think should be addressed early?

Please share examples, scenarios, or even counterpoints — the more perspectives we gather, the stronger this suggestion can become.

[brianrourkeboll]

There is a language suggestion for this here: fsharp/fslang-suggestions#1079.

The main reason that hasn't gone anywhere is that no one has come up with a concrete proposal for how precedence would be managed for such operators: fsharp/fslang-suggestions#1079 (comment).

Re my earlier comment:

As discussed in the comments in the original submission, this is a minefield.... Deciding the precedence for such operators is really hard. It would also create swathes of unreadable F# code. I'll close this since we've previously decided not to do this in F# 2.0, and there has not yet been a major change of circumstance to warrant altering this which addresses the concerns. -

Is there any concrete proposal for precedence for such operators? That's the key missing ingredient, and it's really impossible to proceed without a proposal.

[allan-mattos]

Thanks for raising the precedence issue — I agree that without a concrete proposal it’s impossible to move forward.
As a starting point, here’s a simple precedence table:
a∈AUB∩C\D
1 U -> AUB
2 ∩ -> (AUB)∩C
3 \ -> ((AUB)∩C)\D)
4 ∈ -> a ∈ ((AUB)∩C)\D))
Parentheses can always be used to disambiguate. I’d love to hear whether the community thinks this mapping is reasonable, or if alternative precedence levels would be better.

[vzarytovskii]

My personal opinion is that anything which is hard to type on common ANSI/ISO keyboards makes user experience worse, including allowing optional use, because you know people will abuse it.

[allan-mattos]

I believe this would improve the experience for people in general, as well as for the user!
Currently, most people who own a computer also have basic math skills, which enables them to understand symbols like Union, belongs to, intersection, and difference much better than */&#, for example.

Furthermore, if someone were to start learning how to use a computer today, they would already have an additional motivation to link it to what they learn in mathematics at school, without the need for additional barriers or intermediate keys, which mean countless other things, depending on the context, you know!?

This would be a masterstroke! It would set a precedent for a new era in IT, and I, personally, wish it were an invention attributed to Microsoft. This would bring mathematics and IT even closer together, in addition to facilitating the work of programmers and programming languages ​​in general: Instead of so many different symbols, they would basically use the same ones!

If children had a little more opportunity to link what they learn in school with programming, that is, to correlate theory with practice, or even to learn mathematics from the beginning using computer science and programming, we simply wouldn't have any more college dropouts. I believe that most dropouts occur because people can't immediately apply what they learn in school in childhood.

But you touched on a very important point, my dear friend, currently we need approximately 17 more symbols integrated into the keyboard's numpad, which means only 7 more keys on the numpad, each with two or three symbols: ( ∪ ∩ ); (∈ ∉); (∅ ≠); (∀ ∃ ∄); (∧,∨, ¬); (=> <=>); (⊂ ⊄, ⊃)
Only 7 keys would occupy an almost insignificant space on the keyboard, and why don't we have this yet?

They would be positioned above |Num Lock|; |/|; |*|; |-| and to the right of |-|; |+|; and |Enter|

Consider it! ;)

Big hug!

[Happypig375]

Not being able to type directly on a keyboard shouldn't be an issue as autocompletion can suggest ∪ if union is typed, for example. Client-side input methods can also mitigate this issue.

[allan-mattos]

That's great, but nothing compares to having those symbols on the keyboard. I would have started programming much earlier and never stopped. I'd still be glued to the computer, you know?! 😂