04:06 <yunxing> sspi: We've figured out why your previous patch didn't work (remember that?)

04:07 <yunxing> There was a shift/reduce conflict on LPAREN as we discussed before. I was wondering why it wan't reported.

04:09 <yunxing> It turned out that it wasn't reported because we set the associativity of LPAREN to "nonassoc". In this case, according to yacc/menhir's behavior, the S/R conflict is silently ignored.

06:15 <sspi> yunxing: interesting, probably explains also why I got the syntax errors (from what I read this is the default behaviour in that case)

06:20 <yunxing> sspi: right. The control of precedence associativity in ocamlyacc is pretty coarse grained. We can't set a precedence of an operator without setting its associativity, which then automatically resolves some conflicts for you in an undesired way. Menhir inherits this interface and has the same behavior. Menhir's team was thinking about to add more finer

06:20 <yunxing> grained knobs. But that would require much more work to do while the demand for the feature is not that high.

08:28 <sspi> yunxing: any important reason why OCaml is still stuck on ocamlyacc? from what I see (not an expert) there seems to be more momentum with Menhir

08:40 <companion_cube> ocamlyacc's runtime is in C, I believe, unlike menhir's

08:41 <companion_cube> but there are some mails on the ML archive that explain why

11:30 <sspi> companion_cube: tnx, I'll look into that

13:37 <spion> whats blocking OCaml 4.03 support? :)

17:32 <yunxing> sspi: There is a huge pr that migrates ocaml itself to menhir

17:32 <yunxing> spion: AFAIK we are waiting for Merlin support for 4.03

17:33 <spion> oh ok.

17:33 <yunxing> spion: KC already has a PR that upgrades reason to 4.03

17:55 <sspi> yunxing: good stuff :-)

17:55 <sspi> chenglou: how is jengaboot going?

17:56 <chenglou> bsansouci is making it work with ocaml files too

17:57 <chenglou> We're gonna use it a bit more in the reason repo itself

17:57 <companion_cube> I noticed that visual-studio-code has reason support, but not vanilla OCaml

17:57 <chenglou> Atom-reason already uses it

17:58 <chenglou> companion_cube: aha, that might be the work of one of our friends? Cc bsansouci

18:39 <bsansouci> companion_cube: yeah i think schmavery was working on vanilla ocaml support for VSC. Do you have a link to the reason thing for VSC?

18:40 <Algebr> How to use js_of_ocaml.ppx with rebuild? Was being finicky with me last time I tried briefly

19:17 <companion_cube> https://marketplace.visualstudio.com/items?itemName=kcieslak.reason

19:19 <bsansouci> wow

19:19 <bsansouci> nice

19:39 <schmave> companion_cube: It looks like that reason vscode extension isn't really finished.. seems to just be the example project. https://github.com/Krzysztof-Cieslak/vscode-reason/blob/master/src/extension.ts

19:40 <companion_cube> aww

19:40 <schmave> I've been working a little on an ocaml extension for vscode that's a little further along.. Supports syntax highlighting and some snippet autocompletion as well as automatic reformatting. Working on trying to integrate with merlin. My plan is to finish the support for ocaml first but write it in such a way that it should be trivial to adapt it fo

19:40 <schmave> r use with reason.

19:41 <schmave> It's still pretty rough but this is what I have so far: https://github.com/Schmavery/vscode-ocaml

19:43 <companion_cube> I'd think it was close to atom, wrt plugins

19:44 <schmave> I wouldn't be surprised if it doesn't run right now lol. Still figuring out the best way to do everything using the vscode extension api and debugging my communications with merlin.

19:45 <schmave> Yeah, it's possible that the atom plugin could be adapted to run on vscode. I haven't had a chance to investigate that yet, but I've been stealing some logic to talk to merlin from the atom plugin.

21:19 <sspi> does refmt keep any "styling" from the input file - or is it all changed?

22:13 <yunxing> sspi: what do you mean by "styling"?

22:15 <sspi> yunxing: for instance I put an empty line above a block of code - will that line remain, or will the refmt not care about that empty line?

22:16 <yunxing> It doesn't. We have a task tracking this: https://github.com/facebook/reason/issues/161