merlin

ng the use of type signatures at function boundaries (which also lets it offer world-class error messages). > Reg. typeclasses, there has been enormous amount of work put into modular implicits (http://ocamllabs.io/doc/implicits.html). It is likely to be the next major features in OCaml along with multicore. I know about implicits. I also know that multicore has been "just around the corner" for a few years now, this does not bode well for implicits (which have also been "in progress" for a long time). This also touches another issue with the OCaml maintainers: little in the way of information seems to filter down to the unwashed masses, and let us not speak of the word "roadmap"...

ing for each token, and resume from the first token that has changed (effectively sharing the prefix). But on the side, we can also run arbitrary analysis on a parser (for error message generation, recovery, syntactic completion, or more incrementality...). # Incrementality, part II Sharing prefix was good enough for our use case (parsing is not a bottleneck in the pipeline). But it turns out that a trivial extension to the parser can also solve your case. Using the token stream and the LR automaton, you can structure the tokens as a tree: - starts with a root node annotated by the state of the automaton - store each token consumed as a leaf in that tree - whenever you push on the automaton's stack, enter a sub-level of the tree (annotated by the new state), whenever you pop, return to the parent node This gives you the knowledge that "when the parser is in state $x and $y is a prefix of the token stream, it is valid to directly reduce the subtree $z". In a later parse, whenever you identify a known (state number, prefix) pair, you can short-circuit the parser and directly reuse the subtree of the previous parse. If you were to write the parser by hand, this is simply memoization done on the parsing function (which is defunctionalized to a state number by the parser generator) and the prefix of token stream that is consumed by a call. In your handwritten parser, reusing the objects from the previous parsetree amounts to memoizing a single run (and forgetting older parses). Here you are free to choose the strategy: you can memoize every run since the beginning, devise some caching policy, etc (think about a user (un)commenting blocks of code, or switching preprocessor definitions: you can get sharing of all known subtrees, if this is of any use :)). So with part I and II, you get sharing of subtrees for free. Indeed, absolutely no work from the grammar writer has been required so far: this can all be derived by the parser generator (with the correctness guarantees that you can expect from it, as opposed to handwritten code). A last kind of sharing you might want is sharing the spine of the tree by mutating older objects. It is surely possible but tricky and I haven't investigated that at all. # Error messages The error message generation is part of the released Menhir version. It is described in the manual and papers by F. Pottier (like http://dl.acm.org/citation.cfm?doid=2892208.2892224, PDF available on http://gallium.inria.fr/~fpottier/biblio/pottier_abstracts.h...). I might be biased but contrary to popular opinions I think that LR grammars are well suited to error message generation. The prefix propery guarantees that the token pointed out by the parser is relevant to the error. The property means that there exist valid parses beginning with the prefix before this token. This is a property that doesn't hold for most backtracking parsers afaik, e.g PEG. Knowledge of the automaton and grammar at compile time allow a precise work on error messages and separation of concerns: the tooling ensures exhaustivity of error coverage, assists in migration of error messages when the grammar is refactored, or can give an explicit description of the information available around a given error. This is not completely free however, sometimes the grammar needs to be reengineered to carry the relevant information. But you would have to do that anyway with a handwritten parser and here the parser generator can help you.... If you have such a parser generator of course :). Menhir is the most advanced solution I know for that, and the UX is not very polished (still better than Bison). It is however a very officient workflow once you are used to it. So LR is not the problem, but existing tools do a rather poor job at solving that kind of (real) problems. # Recovery In Merlin's, recovery is split in two parts. The first is completion of the parsetree: for any prefix of a parse, it is possible to fill holes in the tree (and thus get a complete AST). This is done by a mix of static analysis on the automaton and user guidance: for major constructions of the AST, the grammar writer provide "dummy" constructors (the node to use for erroneous expressions, incomplete statement, etc). The parser generator then checks that is has enough information to recover from any situation, or point out the cases it cannot handle. It is not 100% free for the grammar writer, but for a grammar such as OCaml one it took less than an hour of initial work (I remember only a few minutes, but I wasn't measuring properly :)). It is also a very intuitive step as it follows the shape of the AST quite closely. The second part is resuming the parse after an error (we don't fill the whole AST every time there is an error; before filling holes we try to look at later tokens to resume the parse). There is no big magic for that part yet, but the heuristic of indentation works quite well: constructions that have the same indentation in source code are likely to appear at the same depth in the AST, and this is used to decide when to resume consuming tokens rather than filling the AST. I have a few lead for more disciplined approaches, but the heuristic works so well that it isn't an urgency. # Conclusion I would say that if I had to write a parser for a language for which a reasonable LR grammar exists, I will use a (good) parser generator without hesitation. For the grammars of most programming languages, LR is the sweet spot between parsing expressivity and amenability to static analysis.

ml, here are a few useful resources - - Real World OCaml [RWO] - https://realworldocaml.org/ - Using, Understanding, and Unraveling the OCaml Language - http://caml.inria.fr/pub/docs/u3-ocaml/index.html - Developing applications with OCaml - http://caml.inria.fr/pub/docs/oreilly-book/html/index.html - System programming in OCaml - https://ocaml.github.io/ocamlunix/ocamlunix.html Lastly, if you are out of ideas on what to build with OCaml, try out these courses for some challenging programming assignments - Functional Programming (Princeton) : http://www.cs.princeton.edu/~dpw/courses/cos326-12/info.php - Programming Languages and Compilers (UIUC): https://courses.engr.illinois.edu/cs421/fa2014/

guarantees and would lead to many thorny issues. > Polymorphism Causes Run-time Type Errors Polymorphic equality and comparison can definitely be a source of confusion. Hopefully in the future we will have module implicits and be able to solve this issue similarly to how Haskell does it. > No Macros Again, this is more of a "my language is not LISP" complaint. Ocaml has camlp4, which is not a full-blown macro system but allows for a large variety of syntactic extensions to the language. However, camlp4 was tricky to maintain in sync with the original language so nowadays the community is moving towards simpler ppx transformers: http://whitequark.org/blog/2014/04/16/a-guide-to-extension-p... > Record field naming hell This got much better in more recent Ocaml versions, which let you have multiple records with the same field name living in harmony. > Syntax I'll have to agree with this one. Ocaml definitely doesn't have the prettiest syntax. > No (ad-hoc) Polymorphism This is a price to pay for keeping the type system sane. More flexible arithmetic coercion rules would also get in the way of type inference, which is a really nice thing about Ocaml. > Inconsistent function sets Its a bit less awful if you use one of the "replacement standard libraries", such as Containers, Core or Batteries. But yes, the suckyness of the standard library is a huge pain point. > Arithmetic's readability I don't think defining custom operators is as bad as the author thinks here. Their precedence is defined by the symbols you use so a new multiplication operators should behave similar to all the other ones. But yes, the monomorphic operators really are annoying. As I said before, I'm really looking forward to module implicits (sadly, it seems we'll have to wait at least until the version after the next one though) > Order of evaluation This one is even worse than he says. Order of evaluation is undefined and when compiling to bytecode its different from when its compiled to native code (one is left-to-right and the other is right-to-left) > No implicit forward declarations Being able to shadow existing definitions is pretty nice sometimes. Haskell does the "declarations are recursive by default" thing and it sometimes gets in the way. > Standard Library Sucks Can't argue against that. But at least there are replacement libs you can use to make it suck a little bit less. > OMake Nowadays I think people are moving towards ocamlbuild instead.