gravity VS otpcl

I found out that the Parrot programming language (https://github.com/parrot-language/parrot) did copycat line by line my Gravity programming language (https://github.com/marcobambini/gravity).

I know that I used a very permissive license and that the project can be forked and modified by anyone but this is a theft more than a fork.

What can I do in this situation?

This is gonna be subjective, because it depends on what your priorities are.

The two alternatives at the top of my list are Gravity and Wren. They are both designed for the same general profile that Lua has—a scripting language, safe to use, embeddable, with a small VM (low code size).

- https://github.com/marcobambini/gravity

- https://wren.io/

The language design choices are nice and familiar to people who are used to other existing languages. Lua is a bit radical.

Two other options are AngelScript and Squirrel, which are both a bit older and more mature than Gravity and Wren. In my opinion they are

- http://www.angelcode.com/angelscript/

- http://squirrel-lang.org/

Finally, it’s much more feasible these days to embed something like Mono, and Guile has gotten a lot better.

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.