# \[ANN\] first release of nice\_parser
**URL:** https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175
**Category:** Community
**Tags:** announce
**Created:** [July 29, 2019, 9:49pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175 "2019-07-29T21:49:52Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [July 29, 2019, 9:49pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/1 "2019-07-29T21:49:52Z")
I’m pleased to announce the first release of [nice\_parser](https://github.com/smolkaj/ocaml-parsing), a single functor library that wraps your {menhir, ocamlyacc}-generated parser with a nice, high-level interface with beautiful loaction-aware error messages:
```ocaml
opam install nice_parser
ocaml
#use "topfind";;
#require “nice_parser”;;
#show_module Nice_parser.Make;;
module Make :
functor (P : Nice_parser.RAW_PARSER) ->
sig
type token = P.token
type result = P.result
exception LexError of { msg : string; loc : Location.t; }
exception ParseError of { token : token; loc : Location.t; }
val pp_exceptions : unit -> unit
val parse_string : ?pos:Lexing.position -> string -> result
val parse_chan : ?pos:Lexing.position -> in_channel -> result
val parse_file : string -> result
end
```
The library relies on OCaml 4.08’s new [source highlighting mechanism](https://github.com/ocaml/ocaml/pull/2096) for pretty lexing and parsing errors,
```auto
File "examples/illegal.katbb", line 1, characters 10-17:
1 | this!; is illegal!; isntit?
^^^^^^^
Error: [parser] unexpected token
```
but can also be used with earlier versions of OCaml.
The [nice\_parser repository](https://github.com/smolkaj/ocaml-parsing/) includes an example that helps you get started with your own parser in seconds. The API is documented [here](https://smolka.st/ocaml-parsing/nice_parser/index.html).
Happy parsing!
---
### Author:  [@perry](https://discuss.ocaml.org/u/perry)
#### Post date: [July 29, 2019, 9:50pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/2 "2019-07-29T21:50:54Z")
Cool! Any possibility of supporting Sedlex for the Unicode fans?
---
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [July 29, 2019, 9:55pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/3 "2019-07-29T21:55:16Z")
I don’t have time to work on it myself in the immediate future, but would very much appreciate a pull request. I agree it would be great to support sedlex.
---
### Author:  [@Armael](https://discuss.ocaml.org/u/Armael)
#### Post date: [July 29, 2019, 10:37pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/4 "2019-07-29T22:37:07Z")
Nice idea! And happy to see enthusiasm about my error highlighting code :-).
On the implementation side however, I would recommend against hijacking the compiler’s `Location` module as you seem to be doing currently. Relying on this is quite hackish and fragile, and may break in future versions of ocaml (there’s no retro-compatibility guarantees made for compiler-libs in general; ocaml-migrate-parsetree provides _some_ support but `Location` is borderline).
Even if it’s a bit more work, I think it would make sense to package the source highlighting code that currently lives in the compiler as a standalone library. I wanted to do that actually, after my initial implementation in the compiler, but I haven’t had the time yet. I think it would make a lot of sense to integrate it into your nice\_parser library!
Unfortunately, I will have very little time to write code myself in the coming month, but otherwise I’ll be happy to help with reusing my code. I think it makes a lot of sense to have it as part of a more generic library than simply in the compiler’s code base, since it’s a piece of code that’s useful and also a tad annoying to reimplement.
---
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [July 30, 2019, 5:40am UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/5 "2019-07-30T05:40:17Z")
> [@Armael](#):
>
> happy to see enthusiasm about my error highlighting code :-).
I think that little usability improvements like that can go a long way. 🙂 Thanks for making that happen! I also think that now that we have this infrastructure, every parser wirtten in OCaml should benefit from it.
> I think it would make sense to package the source highlighting code that currently lives in the compiler as a standalone library. I think it would make a lot of sense to integrate it into your nice\_parser library!
I agree this would make a lot of sense, and it would be wonderful to integrate it with nice\_parser! (Unfortunately I also won’t have time for this anytime in the near future.)
> [@Armael](#):
>
> I would recommend against hijacking the compiler’s `Location` module as you seem to be doing currently. Relying on this is quite hackish and fragile, and may break in future versions of ocaml (there’s no retro-compatibility guarantees made for compiler-libs in general; ocaml-migrate-parsetree provides _some_ support but `Location` is borderline).
Your points are of course correct. But there are also some good arguments in favor of the current design:
- Because we’re hijacking compiler modules, (i) nice\_parser has less than 100 LoC and (ii) will profit – for free – from future improvements on the compiler.
- I’m not worried about fragility. Should the interfaces change in the future, we only have to release a new version of nice\_parser. We can maintain backwards compatibility using something like [ppx\_optcomp](https://github.com/janestreet/ppx_optcomp). And because there is so little code, doing this will be trivial.
Putting things in a standalone library, as you suggested, makes of course sense, but will also result in a much larger library with a non-trivial maintenance burden.
I’m not against the standalone library idea, I just wanted to point out that there are pros and cons, and that maybe fragility is not really an issue. What do you think?
---
### Author:  [@dbuenzli](https://discuss.ocaml.org/u/dbuenzli)
#### Post date: [July 30, 2019, 7:49am UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/6 "2019-07-30T07:49:24Z")
> [@smolkaj](#):
>
> I’m not against the standalone library idea, I just wanted to point out that there are pros and cons, and that maybe fragility is not really an issue. What do you think?
In general things that depend on unstable parts of OCaml and that may break on any new OCaml releases are bad for the eco-system. They are a burden both for the OCaml compiler developer which can’t test their changes on meaningful samples of the `opam-repository` and for the larger eco-system and end-users by the amount of work and churn that is needed on new OCaml releases (the ppx cancer is a good example of this).
---
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [July 31, 2019, 4:59am UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/7 "2019-07-31T04:59:00Z")
This makes sense from a more holistic point of view. Maybe this suggests that the current design is acceptable as long as the library has few dependents (currently 0), but no longer acceptable if it sees strong adoption? Strong adoption would also justify an increased maintenance burden.
---
### Author:  [@perry](https://discuss.ocaml.org/u/perry)
#### Post date: [August 3, 2019, 3:21pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/8 "2019-08-03T15:21:42Z")
Maybe you could write up a good TODO list for nice\_parser including the interfaces you would want from a library that was detached from the compiler itself? It isn’t as good as someone having the time to do the work, but it makes it slightly more likely that someone would notice that these things need doing.
---
### Author:  [@Armael](https://discuss.ocaml.org/u/Armael)
#### Post date: [August 4, 2019, 4:13pm UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/9 "2019-08-04T16:13:31Z")
Well, coming up with nice interfaces is the hard part, the rest is simply copy-pasting code from the compiler.
Anyway, I’ve just done most of the required work, I think:
> **[Armael/pp\_loc](https://github.com/Armael/pp_loc)**
>
> Contribute to Armael/pp\_loc development by creating an account on GitHub.
This standalone mini library isolates the pretty-priting code, and I’m relatively satisfied by its interface. The name could probably be better, I’m open to suggestions :-).
The library needs a bit more packaging work (just the usual stuff), and I also haven’t really tested it, but it should work, hopefully.
I’ll also gladly give commit rights to anyone that wants to actually use it (I won’t, in the near future)!
---
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [August 5, 2019, 7:24am UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/10 "2019-08-05T07:24:22Z")
Awesome!
I would be happy to take care of the packaging.
We can integrate it with nice\_parser as a first test, though I can’t promise that I find time for it immediately.
---
### Author:  [@smolkaj](https://discuss.ocaml.org/u/smolkaj)
#### Post date: [August 5, 2019, 8:39am UTC](https://discuss.ocaml.org/t/ann-first-release-of-nice-parser/4175/11 "2019-08-05T08:39:19Z")
RE names, “quote\_loc” is not much better but maybe slighlty more descriptive.