oxide-lang VS otpcl

well this exists.

Nice! A while ago I have worked on a similar project: Oxide. So I'll share my thoughts based on that.

Polishing as type type casting for my hobby rust-like language. It works just fine, but have to think semantics better for edge cases

https://github.com/tuqqu/oxide-lang (there are examples there!)

I guess I can chime in on the "by hand" front, since that's how I ended up going about the first non-trivial parser I wrote[1]: https://github.com/otpcl/otpcl/blob/master/src/otpcl_parse.e...

I'd say the difficulty was moderately high, but that was with no real prior experience with parsers. With that water under the bridge, I'd now rate it at around moderate effort. And the result was gaining a clear and precise understanding of the implicit state machine transitions, and being able to control exactly where and how those transitions happen, such that I didn't really need much of a lexer (the "lexer" just tags each character with its position, so that I didn't have to track that separately in the actual parser code itself).

That said, the result is a bit of a tangled mess; it didn't start that way, but eventually the parsing logic got complex enough that I needed to resort to Erlang's preprocessor macros, and while the end result is manageable through some judicious organization, in hindsight I probably could've done the same with functions, and in a more reusable and maintainable way. If I ever get around to another parser rewrite, I might try using parser combinators or some approximation thereof instead.

----

[1]: Technically the second or third, since I rewrote it a couple times as one can see from the commit history - although said history is a bit hard to pin down across all the renames of the relevant file.