OCaml support

[beajeanm]

Describe the language you want support for (compiler, specificities)
I'd like an interpreter for OCaml that uses utop and that work with detected filetypes ml, mli.

Support Level to achieve
Block-level support is enough for me....

Additional context
I've given https://opam.ocaml.org/blog/about-utop/ as the repl, but the ocaml command is also a repl so it may be an option if that's easier to work with. (I'm not sure what's required from the repl).
OCaml can be interpreted and should support fairly advance repl features, but I'b be happy with block support.

[michaelb]

I'll work on it :-)

If it's not too much trouble I'll look into having REPL support as well

[michaelb]

I'm getting close to something ready to merge:

A new interpreter is available from the 'dev' branch, named 'OCaml_fifo'. You can try it out if you want (you'll need to compile sniprun locally, and for that you'll need the Rust toolchain: use the post-install command: bash ./install.sh 1)

Bloc-level support from both 'utop' and the default interpreter 'ocaml'

REPL support, but only with 'ocmal'. Utop is too 'fancy' on its stdout to communicate. REPL behavior is not enabled by default.

[beajeanm]

I must have missed something in the configuration.
Ocaml is listed as supported.

but evaluating a block trigger the generic interpreter, with an empty results.

Trying something similar with python, works as expected, so it seems the plugin work in general.

filetype=ocaml in my test.

[michaelb]

filetype=ml (or mli) should work better

I didn't think twice and just hardcoded the compatibility with 'ml' and 'mli'. I'll add that as well

In the meantime, you can set the 'use_on_filetypes' key in the configuration (see documentation to force the OCaml_fifo interpreter on 'ocaml' filetypes

[beajeanm]

Sorry, that's my fault, I've put the file extension instead of the filetype in the ticket. 🤦🏾
Let me try that.

[beajeanm]

• With use_on_filetypes block mode works great for utop and ocaml.

• Repl mode works too, the only unexpected behavior is I'm force to send ;; (which is the separator in the top level).
  I mean:

print_endline "Hello, world"

works fine in block mode, but fails if repl is enabled, and I have to send that instead:

print_endline "Hello, world";;

• For utop, I've dug around, it's possible to disable most of the fanciness if we send #utop_prompt_dummy;; to the running process.

In any case, it's already very functional for me, thanks for the quick turn around 😄

[michaelb]

Repl mode works too, the only unexpected behavior is I'm force to send ;; (which is the separator in the top level).

Isn't it a normal behavior ? Using the REPL like a typical OCaml novice feels like ';;' is mandatory at the end of each statement. 1-statement files look like the only exception to this rule, be it through sniprun or not:

this will fail even in no-REPL mode

print_endline "Hello, world"
print_endline "Hello, world"

Is there something obvious I'm missing ?

[beajeanm]

No, you are totally correct on that point.
I think it comes to ocaml oddities: ;; are mandatory in the REPL, but completly optional in a "proper" source file (and most people don't use them).
So if I'm editing a regular ocaml file and sending bits of it to the REPL through sniprun, I have to remember to sprinkle it with extra ;; that I would not have bothered with otherwise. But I can live with it :)

[michaelb]

what is a "proper" ocaml source file is quite alien to me, but hey, if it's okay with you...

(I mean, I can't conceivably parse ocaml statements (that may be multi-line) to automatically add ';;' at their end)

Is the non-REPL bloc-mode at least free of such hassle ? My 30-second testing says so, but if you confirm, I'll close this issue, merge the code and release a new version

[beajeanm]

Yes, it works as expected, both for "utop" and "ocaml"

[michaelb]

v1.3.0 is released