Skip to content

OxCaml modes - #146

Open
314eter wants to merge 6 commits into
tree-sitter:masterfrom
314eter:oxcaml-modes
Open

OxCaml modes#146
314eter wants to merge 6 commits into
tree-sitter:masterfrom
314eter:oxcaml-modes

Conversation

@314eter

@314eter 314eter commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Adds support for OxCaml modes and modalities.

The main difficulty was to get modes to work with function types. The left side of a function_type can only be a _simple_type, not a _type. But if the parser encounters let x : t @, it needs to choose if t is a _simple_type or _type, since it can't backtrack later. But depending on if it continues with let x : t @ mode = _ or let x : t @ mode -> t = _, the correct choice is different.

The easy solution would be to make the left side of function_type a _type, and use precedences to make sure everything is still parsed correctly. That almost works, except for

module M : T with type t = t as 'a -> t

which will then be parsed as T with type t = (t as 'a -> t) instead of (T with type t = t as 'a) -> t. I couldn't find a way to avoid that.

The alternative solution is to inline _type. That works, but it needs to be inlined in a lot of places, which results in a lot more states. This PR doubles the parser in size.

The other issue was polymorphic types. I had to refactor them a bit to be able to resolve conflicts like let x : 'a . 'a @ mode -> t = _. This has an impact on the resulting tree-sitter AST.

@314eter

314eter commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator Author

I reduced the number of states by adding conflicts instead of inlining rules to avoid them. I usually prefer to keep the grammar conflict free, but here it's not worth the increased complexity.

@314eter 314eter mentioned this pull request Sep 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want type_variable dropped?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _ in type _ t = ... is not really a type variable, it's the absence of a type variable. I tried to make the parsing of _ a bit more consistent across the whole grammar, but completely ignoring it here is maybe not the best solution.

Comment thread grammars/ocaml/grammar.js
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants