tao VS pom

If you want some prior work on this, I've implemented effect-objects-as-return-values in my own language Tao, using uniqueness types. There's still work to be done, but I think it's sufficient as a proof of concept that this approach is viable without type soup.

I've personally found through my experiments working on my language Tao that having effects be a property of the return value and not the function itself is very useful and opens up a lot of doors, like iterators that generate effectful values and more precise control over when side effects occur and in what context.

If you’d like to see some examples of great error messages written by a language with a parser combinator, I recommend you check out tao, which is parsed via chumsky, and provides rust-like error messages with the help of ariadne! I have been fiddling with writing my own language for a while now, and after trying out the alternatives, I found Chumsky to be great to work with, and can not recommend it enough. There are also great examples that you can find in the repo as well!

Tao: A statically-typed functional language\ (0 comments)

I've been developing both throughout the development of Tao, my own hobby language. It's since developed quite an extensive syntax (see here for an example: https://github.com/zesterer/tao/blob/master/examples/99.tao), so you can count it as evidence that chumsky scales to complex grammars: https://github.com/zesterer/tao

pom

Maybe a parser combinator library is not what you want? One alternative might be writing an expression parser without a library at all: https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html (Depending on the grammar you are parsing a Pratt parser might actually be a good fit!) A PEG might also be more suitable for your use case, like pom.

I saw the performance comparison against pom, pom is unfortunately quite slow compared to an handwritten parser as it boxes most (all?) parsers so you may want to compare against a handwritten parser, or at least something in the same ballpark (for reference, combine's json benchmark on the same data is about 6x faster with "good errors", when optimized to work on &str-like input it is about 12x faster, nom or a hand written parser may be another 10-20% faster than that, if I remember correctly.) From a brief skim of the code, I don't see anything that would hinder it from at least closing that gap however.

Everyone on this sub seems to be using nom. In my experience I find pom to be intuitive and have to write less code. Maybe it's just me I'm having a hard time understanding nom which has a lot of function calls rather than less.If you compare both the json examples on both projects, the pom example is a lot clearer to read and a lot shorter.