Re: pyrex like compiler

Mark Hahn wrote:

When considering how to ImplementPyrexForProthon,  I of course was thinking
of the grandiose idea of having 100% of Prothon running in the compiled C
code.

I noticed that Prorex (that does not roll off the tounge easily <grin>)
could be compiled in a single pass as Prothon is compiled and that the
existing Prothon compiler could be easily modified to spit out C as it now
spits out bytecodes. I would have to add the extra syntax for cdef's and the
ctypes, etc. of course.
Then I started wondering if the interpreter could be made to run the
extended syntax. Could the new extended Prorex be interpreted? I quickly
realized the only limiting factor would be the linking and calls to the
external C libraries. So I wondered if we limited the interpreter interface
to external libraries to DLL's only if it could work.

There are two uses for C extensions. One is getting extra speed, the second
is interfacing to foreign C/C++ functions. Users of Psyco claim that psyco
is so fast that there is no need for the first use of C extensions. Prothon
is planning on implementing Psyco as the standard interpreter. That leaves
only foreign function interfaces (FFI).

Why not add foreign function interfaces as a language feature to the Prothon
interpreter? In other words add the Prorex language not as extensions but as
a standard language feature. Prothon would not be extendable by C, it would
be extendable to C, natively. Prothon would no longer need any C extensions
at all. There would no longer be a C api to support.

The only time you might need to get your hands dirty with C is for libraries
that don't have DLL support. You would need to take the static library
provided and wrap it in a DLL wrapper. This would be quite rare I think and
easy to do.

Some anonymous person wrote:

At first I was enthusiastic but the second problem below strikes me as a big
problem:

1) Python runs on a wide variety of different CPUs. That's why it comes with
Mac OS and will soon come with Nokia cell phones. Porting a JIT is a pain in
the ass. I think that Prothon should be architected to use pure
interpretation where that is all that is available, JIT where that is
available and native compilation where that is available. As you said,
spitting out C code that calls into the interpreter is not rocket science.

2) There are many interfaces that only expose important constants and
typedefs in C header files. Pyrex can reference those typedefs and constants
without redefining them because it compiles to C. A runtime FFI cannot ask
the compiler "at what offset in the struct is the foo member on this
operating system on this hardware with this version of the library?" This is
why COM and XPCOM were invented. They provide language neutral encodings for
all that stuff that is usually in the header file. It might be worth
considering XPCOM as an FFI mechanism.