Who's developing language interpreters in PyPy
Hi, I've been reading up on pypy and is really interested in the idea of implementing X language interpreters in pypy, where X can be any known programming language. Do we have a knowledge of who is developing or interested in which X-to-pypy interpreter so there's no competition nor duplication of work? Personally I have some interests in a few languages that I know, such as R and pascal. Cheers maurice
Hi Maurice! 2007/4/22, Maurice Ling <mauriceling@gmail.com>:
Short overview: The following interpreters are in the PyPy repository currently (or will be, in the case of Scheme): - Python (various people) - Prolog (me) - JavaScript (Leonardo Santagada) - Scheme (Jakub Gustak, not yet started) In addition, Christopher Armstrong is working on "SafeLisp": https://code.launchpad.net/~subol-hackers/subol/safelisp-rpython
Personally I have some interests in a few languages that I know, such as R and pascal.
I don't really know either of them very well, but I imagine that the problem with R would be that you would have to implement all sorts of numerical functions (which is a lot of effort) or interface to existing C libraries (which is not much fun, since the rctypes are a mess, currently). Cheers, Carl Friedrich
Em 22/04/2007, às 08:07, Maurice Ling escreveu:
Yep it is... but probably more interesting to interpreters...
Pascal should be easier to do, but you have to tell us exactly what you want. If you are planning to do a pascal compiler it would be the first compiler in pypy. If you are thinking on a pascal interpreter this could be quite easy to do but then you need to have some problem with current pascal compilers that you want to fix. I think this could be used on teaching compilers, as understanding a pascal compiler written in python would be much more comprehensible than a C or pascal one. -- Leonardo Santagada santagada@gmail.com
Thanks Leonardo
I don't actually use Pascal these days but it's just the first programming language I learnt. So it's more like a childhood dish kinda thing, just refuse to let it go completely although I do agree with you that a Pascal compiler written in Python will be more comprehensible than one written in C or Pascal. And it may just seems oxymoronic to think about implementing a C compiler in PyPy. My current langauge kit is Python/C/Java/R/SQL/UML. So I presume there's a bit more interest in R than in pascal and implementing a R interpreter in python will reduce the need for RPy in many cases (I think). Otherwise, I may go on a total tangent and try working on modeling/simulation languages like Modelica/SBML combination or even a UML simulator in RPython, which may be more useful to my future employment. So yes, I'm kinda polling interests here... Any suggestions? Thanks Cheers maurice
Em 22/04/2007, às 21:24, Maurice Ling escreveu:
Thanks Leonardo You're welcome
So yes, I'm kinda polling interests here... Any suggestions?
If you make an R interpreter using pypy we would probably still need RPy to use R inside python. What you could do is implement Numeric (I don't know how it is called this days, maybe numpy or numarray) in pypy, that probably helps to make python able to do the same kind of work as R is used to today... and maybe even faster :) Just remember implementing Numeric on pypy is going to be kind of hard... in exchange you will probably get your hack skillz up to a demi god level :) Good luck, -- Leonardo Santagada santagada@gmail.com
Leonardo Santagada wrote:
Numpy appears to be the official merger between Numeric and Numarray. In general you'd hope PyPy will eventually grow ways to reuse important bits of C-based Python infrastructure for the implementation of non-Python language. Or can it already do so through rctypes? It sounds a bit odd to use Numeric for the implementation of R that way, but it'd make sense to be able to do so, right? Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits, though. Regards, Martijn
"Martijn Faassen" <faassen@startifact.com> wrote in message news:f0hsqn$d4b$1@sea.gmane.org... |Numpy appears to be the official merger between Numeric and Numarray. *is*, insofar as anything is 'official'. |It sounds a bit odd to use Numeric for the implementation of R that way, |but it'd make sense to be able to do so, right? 'R' is both a (statistics/data analisis) language and an interpreter system. (I have not used it but read some some time ago.) The latter, I presume, is implemented in some combination of C and Fortran, as are NumPy and SciPy. I would not be surprised if the R system used some of the same libraries (BLAS, LinPack, FFTPack, etc). So, if the array concepts are compatible, it make perfect sense to me to base an alternate implemention of R the language on NumPy and the R functions that are already in SciPy. The motivation would either be a) proof of concept of PyPy as a general platform for implementing dynamic languages or b) an implementation with value-added for users (free (if R is not yet), open-source (ditto), access to other Python facilities). | Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits Many to most of 'those bits' have been heavily optimized already, which is why to use them. Terry Jan Reedy
On Mon, 23 Apr 2007 15:13:36 -0400 "Terry Reedy" <tjreedy@udel.edu> wrote:
Yes, but how about this idea: that we would like to take vector expressions, such as the sum of three arrays, X+Y+Z, and instead of creating a temporary array to house X+Y (and then summing with Z), we sum the elements from all three arrays at once. This kind of calculation is very typical in numpy/R, where temporary arrays are created, transversed then destroyed alot, and the CPU cache overheats, and people become generally unhappy. Last year I had a look at teaching the rtyper to understand numpy expressions (see pypy.rpython.numpy), with the idea of heading in this more intelligent direction. This year i discovered the pypy JIT and had a brain orgasm; it would be very interesting to use (+develop) the JIT towards these cache friendly ideas also. It really makes no sense to reimplement R, i think, UNLESS you can interface with the present R libraries. The big strength of R is it's many many libraries for statistics etc. I don't think it's much of an interesting language in and of itself. Simon.
Hi Maurice, On Sun, Apr 22, 2007 at 09:07:08PM +1000, Maurice Ling wrote:
In general, the more interesting languages to try to implement with PyPy are dynamic languages. Of course it's possible, and maybe even nice, to write an interpreter for Pascal. It's just that there is a bias towards dynamic languages, both in what RPython supports and in what the translation toolchain can do with it. Well, you can always try to build a dynamically extensible Pascal environment with automatic memory management :-) Which reminds me to mention that a Smalltalk environment would be a nice project in PyPy. A bientot, Armin.
Hi Maurice! 2007/4/22, Maurice Ling <mauriceling@gmail.com>:
Short overview: The following interpreters are in the PyPy repository currently (or will be, in the case of Scheme): - Python (various people) - Prolog (me) - JavaScript (Leonardo Santagada) - Scheme (Jakub Gustak, not yet started) In addition, Christopher Armstrong is working on "SafeLisp": https://code.launchpad.net/~subol-hackers/subol/safelisp-rpython
Personally I have some interests in a few languages that I know, such as R and pascal.
I don't really know either of them very well, but I imagine that the problem with R would be that you would have to implement all sorts of numerical functions (which is a lot of effort) or interface to existing C libraries (which is not much fun, since the rctypes are a mess, currently). Cheers, Carl Friedrich
Em 22/04/2007, às 08:07, Maurice Ling escreveu:
Yep it is... but probably more interesting to interpreters...
Pascal should be easier to do, but you have to tell us exactly what you want. If you are planning to do a pascal compiler it would be the first compiler in pypy. If you are thinking on a pascal interpreter this could be quite easy to do but then you need to have some problem with current pascal compilers that you want to fix. I think this could be used on teaching compilers, as understanding a pascal compiler written in python would be much more comprehensible than a C or pascal one. -- Leonardo Santagada santagada@gmail.com
Thanks Leonardo
I don't actually use Pascal these days but it's just the first programming language I learnt. So it's more like a childhood dish kinda thing, just refuse to let it go completely although I do agree with you that a Pascal compiler written in Python will be more comprehensible than one written in C or Pascal. And it may just seems oxymoronic to think about implementing a C compiler in PyPy. My current langauge kit is Python/C/Java/R/SQL/UML. So I presume there's a bit more interest in R than in pascal and implementing a R interpreter in python will reduce the need for RPy in many cases (I think). Otherwise, I may go on a total tangent and try working on modeling/simulation languages like Modelica/SBML combination or even a UML simulator in RPython, which may be more useful to my future employment. So yes, I'm kinda polling interests here... Any suggestions? Thanks Cheers maurice
Em 22/04/2007, às 21:24, Maurice Ling escreveu:
Thanks Leonardo You're welcome
So yes, I'm kinda polling interests here... Any suggestions?
If you make an R interpreter using pypy we would probably still need RPy to use R inside python. What you could do is implement Numeric (I don't know how it is called this days, maybe numpy or numarray) in pypy, that probably helps to make python able to do the same kind of work as R is used to today... and maybe even faster :) Just remember implementing Numeric on pypy is going to be kind of hard... in exchange you will probably get your hack skillz up to a demi god level :) Good luck, -- Leonardo Santagada santagada@gmail.com
Leonardo Santagada wrote:
Numpy appears to be the official merger between Numeric and Numarray. In general you'd hope PyPy will eventually grow ways to reuse important bits of C-based Python infrastructure for the implementation of non-Python language. Or can it already do so through rctypes? It sounds a bit odd to use Numeric for the implementation of R that way, but it'd make sense to be able to do so, right? Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits, though. Regards, Martijn
"Martijn Faassen" <faassen@startifact.com> wrote in message news:f0hsqn$d4b$1@sea.gmane.org... |Numpy appears to be the official merger between Numeric and Numarray. *is*, insofar as anything is 'official'. |It sounds a bit odd to use Numeric for the implementation of R that way, |but it'd make sense to be able to do so, right? 'R' is both a (statistics/data analisis) language and an interpreter system. (I have not used it but read some some time ago.) The latter, I presume, is implemented in some combination of C and Fortran, as are NumPy and SciPy. I would not be surprised if the R system used some of the same libraries (BLAS, LinPack, FFTPack, etc). So, if the array concepts are compatible, it make perfect sense to me to base an alternate implemention of R the language on NumPy and the R functions that are already in SciPy. The motivation would either be a) proof of concept of PyPy as a general platform for implementing dynamic languages or b) an implementation with value-added for users (free (if R is not yet), open-source (ditto), access to other Python facilities). | Naturally PyPy wouldn't be able to use its magical optimization abilities on those bits Many to most of 'those bits' have been heavily optimized already, which is why to use them. Terry Jan Reedy
On Mon, 23 Apr 2007 15:13:36 -0400 "Terry Reedy" <tjreedy@udel.edu> wrote:
Yes, but how about this idea: that we would like to take vector expressions, such as the sum of three arrays, X+Y+Z, and instead of creating a temporary array to house X+Y (and then summing with Z), we sum the elements from all three arrays at once. This kind of calculation is very typical in numpy/R, where temporary arrays are created, transversed then destroyed alot, and the CPU cache overheats, and people become generally unhappy. Last year I had a look at teaching the rtyper to understand numpy expressions (see pypy.rpython.numpy), with the idea of heading in this more intelligent direction. This year i discovered the pypy JIT and had a brain orgasm; it would be very interesting to use (+develop) the JIT towards these cache friendly ideas also. It really makes no sense to reimplement R, i think, UNLESS you can interface with the present R libraries. The big strength of R is it's many many libraries for statistics etc. I don't think it's much of an interesting language in and of itself. Simon.
Hi Maurice, On Sun, Apr 22, 2007 at 09:07:08PM +1000, Maurice Ling wrote:
In general, the more interesting languages to try to implement with PyPy are dynamic languages. Of course it's possible, and maybe even nice, to write an interpreter for Pascal. It's just that there is a bias towards dynamic languages, both in what RPython supports and in what the translation toolchain can do with it. Well, you can always try to build a dynamically extensible Pascal environment with automatic memory management :-) Which reminds me to mention that a Smalltalk environment would be a nice project in PyPy. A bientot, Armin.
participants (7)
-
Armin Rigo -
Carl Friedrich Bolz -
Leonardo Santagada -
Martijn Faassen -
Maurice Ling -
Simon Burton -
Terry Reedy