Proof of Concept: explore per-module custom infix operators. #6076

cristianoc · 2023-03-15T12:57:00Z

Add local support for custom infix operators.

Properties:

Per-file, not dependent on project settings.
Opt-in by the user, not mandated (by e.g. a library).
No semantic change, just local view of the same ast.
Supports hover, and jump to definition. Or just scan the file visually to find the definition of symbols (no search codebase for e.g. "!" defined in some far away file)
No effect on parsing and printing performance on normal use.

Example:

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

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

let q = 3 😀 4 💩💩 5

The scope of @@infix is from where it appears until the end of the module (or file if at toplevel).
There's currently no restriction on what can be used as a symbol: any string including keywords. Restrictions can be placed later on, but the core mechanism is well defined regardless (just as with a macro mechanism).

Remove infix.add and infix.remove infix.add should not affect the parser (only the printer) Implement per-module scoping mechanism The annotations only apply to the module they appear in.

hoichi · 2023-03-15T13:54:53Z

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  
}

cristianoc · 2023-03-15T16:25:47Z

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.

mooreryan · 2023-03-15T16:45:43Z

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?

cristianoc · 2023-03-15T17:10:46Z

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.

mooreryan · 2023-03-15T17:19:34Z

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?

cristianoc · 2023-03-15T17:25:40Z

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.

mooreryan · 2023-03-15T17:28:35Z

Thanks, I appreciate the explanation.

ornamentist · 2023-03-15T22:30:46Z

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).

DZakh · 2023-03-16T07:36:07Z

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

ornamentist · 2023-03-16T07:41:33Z

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).

cristianoc · 2023-03-16T07:49:10Z

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.

IwanKaramazow · 2023-03-16T19:06:05Z

res_syntax/src/res_scanner.ml

    String.unsafe_get scanner.src (scanner.offset + 3)
  else hackyEOFChar

 let make ~filename src =
  {
    filename;
    src;
+    srcLen = String.length src;


Thanks 👍

cristianoc mentioned this pull request Mar 15, 2023

Extend infix operators with instructions for the formatter. #6072

Open

cristianoc added the experiment label Mar 15, 2023

Proof of Concept: explore per-file custom infix operators.

8baca4b

Remove infix.add and infix.remove infix.add should not affect the parser (only the printer) Implement per-module scoping mechanism The annotations only apply to the module they appear in.

cristianoc force-pushed the infix-base branch from f66a7c1 to 8baca4b Compare March 15, 2023 13:29

cristianoc changed the title ~~Proof of Concept: explore per-file custom infix operators.~~ Proof of Concept: explore per-module custom infix operators. Mar 15, 2023

IwanKaramazow reviewed Mar 16, 2023

View reviewed changes

fhammerschmidt mentioned this pull request Oct 29, 2023

Modulus Operator #6455

Open

fhammerschmidt mentioned this pull request Mar 27, 2024

Document upcoming infix operators rescript-association/rescript-lang.org#160

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Proof of Concept: explore per-module custom infix operators. #6076

Proof of Concept: explore per-module custom infix operators. #6076

cristianoc commented Mar 15, 2023 •

edited

hoichi commented Mar 15, 2023

cristianoc commented Mar 15, 2023 •

edited

mooreryan commented Mar 15, 2023

cristianoc commented Mar 15, 2023 •

edited

mooreryan commented Mar 15, 2023

cristianoc commented Mar 15, 2023 •

edited

mooreryan commented Mar 15, 2023

ornamentist commented Mar 15, 2023

DZakh commented Mar 16, 2023

ornamentist commented Mar 16, 2023

cristianoc commented Mar 16, 2023 •

edited

IwanKaramazow Mar 16, 2023

Proof of Concept: explore per-module custom infix operators. #6076

Are you sure you want to change the base?

Proof of Concept: explore per-module custom infix operators. #6076

Conversation

cristianoc commented Mar 15, 2023 • edited

hoichi commented Mar 15, 2023

cristianoc commented Mar 15, 2023 • edited

mooreryan commented Mar 15, 2023

cristianoc commented Mar 15, 2023 • edited

mooreryan commented Mar 15, 2023

cristianoc commented Mar 15, 2023 • edited

mooreryan commented Mar 15, 2023

ornamentist commented Mar 15, 2023

DZakh commented Mar 16, 2023

ornamentist commented Mar 16, 2023

cristianoc commented Mar 16, 2023 • edited

IwanKaramazow Mar 16, 2023

Choose a reason for hiding this comment

cristianoc commented Mar 15, 2023 •

edited

cristianoc commented Mar 15, 2023 •

edited

cristianoc commented Mar 15, 2023 •

edited

cristianoc commented Mar 15, 2023 •

edited

cristianoc commented Mar 16, 2023 •

edited