Out of curiosity, will this work?

module Foo = {
  let plus = (x, y) => x + y
  let minus = (x, y) => x - y

  @@infix(("😀", "plus"))
  @@infix(("💩💩", "minus"))
}

module Bar = {
  include Foo

  let q = 3 😀 4 💩💩 5  
}

Out of curiosity, will this work?

module Foo = {
  let plus = (x, y) => x + y
  let minus = (x, y) => x - y

  @@infix(("😀", "plus"))
  @@infix(("💩💩", "minus"))
}

module Bar = {
  include Foo

  let q = 3 😀 4 💩💩 5  
}

No. In other words, the user decides, not the implementor of the module.

See the above property: "not dependent on project settings", and "no semantic change". Include across files, as I assume what the example intends to mean, would need to break both properties.

Couple of questions...(If it is better, I could move these questions in the discuss forum, to not clutter up the pull request.)

What are the precedence and associativity rules for custom infix ops? Will they match OCaml's rules?

So, include doesn't bring the operators into another module...what about open, will that bring operators into scope?

See the above property: "not dependent on project settings", and "no semantic change". Include across files, as I assume what the example intends to mean, would need to break both properties.

^ I'm not really sure what this means...the normal semantic/meaning of open/include is give me everything in the module I'm opening/including. So, making it so the operators will not be included when using include or open, isn't that what is changing the semantics of module inclusion?

What are the precedence and associativity rules for custom infix ops? Will they match [OCaml's]

It's user-defined operators, not a set of canned predefined operators. So there's no set of rules to follow.
It's currently using left-associative like for ++, but making that controllable in the @@infix annotation should not be a problem.

So, include doesn't bring the operators into another module...what about open, will that bring operators into scope?

See the above property: "not dependent on project settings", and "no semantic change". Include across files, as I assume what the example intends to mean, would need to break both properties.

^ I'm not really sure what this means...the normal semantic/meaning of open/include is give me everything in the module I'm opening/including. So, making it so the operators will not be included when using include or open, isn't that what is changing the semantics of module inclusion?

OCaml includes values, modules and types from the included module. A module-level annotation (i.e. a thing starting with @@) is not one of those things. A good analogy is: ocaml include does not include the doc comments (which are represented internally as annotations).
No semantic change means that the ast is EXACTLY the same as if you were not using inifx, so by design there's no way to tell whether a file I'm using has some of those inside.

Thanks for the clarification about the AST and the module level annotations (and the ocaml doc comments analogy). It makes sense to me now, what you are meaning.

When you say "making that controllable in the @@infix annotation", by "that" do you mean controlling precedence and associativity or just associativity? Or, am I just overthinking this, and the use of local infix ops it more a situation of, user shouldn't be making complicated infix ops and combining them in ways that you would even need to worry about it precedence and associativity?

Thanks for the clarification about the AST and the module level annotations (and the ocaml doc comments analogy). It makes sense to me now, what you are meaning.

When you say "making that controllable in the @@infix annotation", by "that" do you mean controlling precedence and associativity or just associativity? Or, am I just overthinking this, and the use of local infix ops it more a situation of, user shouldn't be making complicated infix ops and combining them in ways that you would even need to worry about it precedence and associativity?

Both precedence and associativity could be made controllable. While associativity is standard, making sense of precedence would require documenting the way this is represented internally (what numbers are used for the language's operators). Both are trivial to do in terms of implementation, the question is documentation and complexity of use. It really depends on how frequently those controls would be needed. In doubt, it does not hurt to start small and add features gradually. Much easier than changing/removing later.

Thanks, I appreciate the explanation.

Would this change also allow more use of Unicode characters in identifiers? The use-case I'm thinking of is mathematical objects with widely accepted Unicode character representations (e.g. real numbers, set union, pi, tau, etc).

I wonder what's a use-case for this feature. I can't find any.

I would use it today if available in my tests and assertions about mathematical objects where there is already an accepted infix symbol for the operation (e.g. set union, logical equivalence, group operator, etc).

Would this change also allow more use of Unicode characters in identifiers? The use-case I'm thinking of is mathematical objects with widely accepted Unicode character representations (e.g. real numbers, set union, pi, tau, etc).

A unicode variable identifier can be thought of as an "operator with zero arguments", so the same kind of mechanism would cover it. That said, this application seems very niche.

There's a separate question on whether it would be possible to extend the language with unicode identifiers (a semantic change). Technically, this is possible. However, they are not valid variable names in JS, so the language would have to encode somehow, and produce what effectively would look like garbled output.

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.