Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: support BER MetaOCaml #1211

Open
ale64bit opened this issue Jan 18, 2020 · 6 comments · May be fixed by #2630
Open

Feature request: support BER MetaOCaml #1211

ale64bit opened this issue Jan 18, 2020 · 6 comments · May be fixed by #2630

Comments

@ale64bit
Copy link

Is your feature request related to a problem? Please describe.
When using ocamlformat with BER MetaOCaml sources, the bracket syntax is expanded to the corresponding attributes. For example:

let _ = .<1>.

expands to

let _ = (1 [@metaocaml.bracket])

Describe the solution you'd like
I guess we could argue that BER MetaOCaml is a "dialect" of OCaml and the fix doesn't belong in ocamlformat. However, it would be great if it was supported. Concretely, the bracket syntax (both bracket .<expr>. and escape .~(expr)) should be kept as is.

Additional context
none

@gpetiot
Copy link
Collaborator

gpetiot commented Jan 21, 2020

The problem is that we would need a way to tell the OCaml parser (that we rely on) that .<expr>. is a valid expression, formatting the corresponding attribute in the BER syntax is the easy part.
Once #1026 is merged we would be able to format invalid files, so the parts where you use BER syntax would be ignored and the rest would be formatted.

@Julow
Copy link
Collaborator

Julow commented Jan 21, 2020

@gpetiot BER MetaOCaml is a fork of OCaml. Building OCamlformat with it automatically allows to parse BER syntax, since there is no new AST nodes.
This issue is about OCamlformat's output. BER parser uses [@metaocaml. ..] attributes internally but OCamlformat prints them.

I would be in favor of this feature :)
I wonder how compatibility with different version would work as we rely on ocaml-migrate-parsetree ? (OCamlformat only supports 4.07 to 4.09, though)

@emillon
Copy link
Collaborator

emillon commented Jan 22, 2020

This will at least make the test suite more complicated since we'll emit code that's invalid for the vanilla compiler, as @gpetiot said. So it would have to be gated behind a flag at least.

In any case, extensions are low priority at the moment. It would be easier to support than extensions like cppo or camlp4, but the focus for ocamlformat is vanilla ocaml code for now.

@craigfe
Copy link
Contributor

craigfe commented Oct 19, 2020

I have a small (~50 line) patch that adds MetaOCaml dialect support here, which may be useful to anyone who just wants a quick solution. I have no comment on whether it's worth trying to maintain this upstream.

@hhugo
Copy link
Collaborator

hhugo commented Jan 6, 2023

x-link ocaml/ocaml#11871

@gpetiot
Copy link
Collaborator

gpetiot commented Jan 6, 2023

We will be happy to support this once it is merged in the compiler, we regularly rebase our vendored parser to catch up on the latest syntax.

@hhugo hhugo linked a pull request Nov 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants