How the heck is this supposed to be compiled to Nim?
Hand Optimizing generated nim code , bringing to speed of Nim.
Nim is already speedy. Hand optimizing more often than not performs worse than good optimizers like gcc and clang. And what does this have to do with Python?
In the way Cython/Nutika/Rusthon does?
Cython is a) An extended Python with type specifiers and b) a system that translates Cython language to C code that works in conjunction with the Cython interpreter.
Nuitka is similar but it generates C++ code that works in conjunction with libpython.
Rusthon is a high level Python-like language that compiles to Rust. It also includes a Python to Javascript "transpiler". The Rusthon doc says "Rusthon is a pythonic language with some extra syntax inspired by Go, JavaScript, Rust and C++. Rusthon is written in Python, and uses the native AST parser, and so is able to parse all valid Python code. Some of the dynamic features of Python are lost in translation, depending on the backend." ... Most likely, dynamic features would have major lossage with a Nim backend.
You could start with any of these and try to turn them into transpilers into Nim ... that doesn't seem like a good idea to me, but I'm not much of a visionary. And Cython and Nuitka require an extensive runtime component in order to run Python programs. Rusthon doesn't, but it abandons "some of the dynamic features of Python", which I suspect means it's not a very good choice for use with existing Python code.
I think a Python to Nim translator is a very interesting project.
Rough idea: Modify python/ceval.c so that the opcodes RETURN_VALUE and YIELD_VALUE produce type information for the current PyFrameObject, with a bit of work you can make the Python interpreter annotate everything with types automatically by running the Python code and then translate the Python to Nim via a tool like c2nim.
Well sure it's not perfect, but it should work much better than trying to figure out the types statically. Or at least it should be much less work.
It would be especially a problem with libraries, where you may only be able to run a small subset of the potential clients of the API.
Yeah but that's a feature, so you get the types that are important for your input and not overly generic types that all end up as PyObject.
@Araq , thank you very much for your idea. It is very interesting.
Not related to Py2nim but for experiment: translating whole interpreter to nim can be easily done by doing : pypy > tranlate whole python to c > c2nim > we got python interpreter written in nim.
Good for an experimental project I guess.
pypy > tranlate whole python to c
The (reference) Python interpreter (CPython) is already written in C. (So is Cython.) And Pypy itself is written in RPython and then translated to C ... but that's the version you don't want because ...
we got python interpreter written in nim.
But what's the point? Converted code like that isn't maintainable. It's better to just write a Python interpreter in Nim, if that's what you want.
@jibal @kirbyfan pypy > tranlate whole python to c is actually just an experimental that i have in mind for testing c2nim , not really worth it, it will just generate interpreter in nim . I have seen how (ugly) generated C code by pypy.
py2nim which @araq suggest is actually interesting.