ssize_t
Joined 7 years ago
Karma
68
Submissions
4
Member since
Oct 1
Recent submissions
Comment · 6 years ago
thanks!
Comment · 6 years ago
I think the `#coding:` approach is promising. You have to fit your parsing/transpilation into a pretty small time budget (which is a fun challenge on its own) to keep the startup time hit negligible. The source code gets reparsed serval times in certain cases, e.g. when printing a stack trace, so its a good idea to have some sort of caching mechanism.
As far as parsing goes, if you want to stick with python I've had good success with pyparsing [1], otherwise I have a strong preference to do language-related things in OCaml with menhir [2]. I've toyed with wrapping the Python parser in an OCaml library with decent success [3]. But, of course, unless you're optimizing for fun, it's probably a good idea to stick with Python.
Another, weirder, approach is creating a language that happens to be able to be parsed by the same grammar as python, then using a decorator (or similar) to get the source code or the ast to reparse and transpile. As an example you could have something like `a <- b` be the syntax for an actor model message receive dsl (which is valid python).
[1] https://github.com/pyparsing/pyparsing [2] http://gallium.inria.fr/~fpottier/menhir/ [3] https://github.com/georgek42/pyparser
Comment · 6 years ago
Absolutely :) I "discovered" this when researching implementing a new language on top of python. The decorator is completely unnecessary, so you can have a complete language with custom features built entirely on top of the python interpreter.