[pypy-dev] Questions on the pypy+numpy project

[Bengt Richter]

On 10/18/2011 02:41 PM Armin Rigo wrote:
> Hi,
>
> On Tue, Oct 18, 2011 at 14:19, Stefan Behnel<stefan_ml at behnel.de>  wrote:
>> The other situation is where PyPy does its own thing and supports some NumPy
>> code that happens to run faster than in CPython, while other code does not
>> work at all, with the possibility to replace it in a PyPy specific way.
>
> I think you are disregarding what 8 years of the PyPy project should
> have made obvious.  Yes, some code will not run at all on PyPy at
> first, and that amount of code is going to be reduced over time.  But
> what we want is to avoid a community split, so we are never, ever,
> going to add and advertise PyPy-only ways to write programs.
>
>
> A bientôt,
>
> Armin.

Just the same, I think PyPy could be allowed to have an "import that" ;-)

I think I read somewhere that PyPy's ambitions were not just to serve official Python with
fast implementation, but possibly other language development too. Is that still true?

If one wanted to use PyPy's great infrastructure to implement a new language,
what would be the pypythonic bootstrapping path towards a self-hosting new language?
BTW, would self-hosting be seen as a disruptive forking goal?

If the new language were just a tweak on Python, what would be the attitude towards
starting with a source-source preprocessor followed by invoking pypy on the result?

Just as an example (without looking at grammar problems for the moment),
what if I wanted to transform just assignments such that x:=expr meant x=expr as usual,
except produced source mods to tell pypy that subsequently it could assume that x had
unchanging type (which it might be able to infer anyway in most cases, but it would also
make programmer intent human-perceptible). In similar vein, x::=expr could mean x's
value (and type) would be frozen after the first evaluation.

This raises the question of how would I best tell pypy this
meta-information about x with legal manual edits now? Assertions?

Could you see pypy accepting command-line options with information about specific variables,
functions, modules, etc.? (such options could of course be collected in a file referenced
from a command line option). It is then a short step to create some linkage between the
source files and the meta-data files, e.g. by file name extensions like .py and .pyc
for the same file. Maybe .pym? If so pypy could look for .pym the way it looks for
.pyc at the appropriate time.

Going further, what about preprocessing with a statement decorator using e.g.,

	@@decomodule.fun
	statement  # with suite

to mean the preprocessor at read time should import decomodule in a special environment
and pass the statement (with suite) to decomodule.fun for source transformation with return
of source to be substituted. BTW, during the course of preprocessing, the "special environment" for
importing statement-decorating modules could persist, and state from early decorator calls
could affect subsequent ones.

Well, this would be Python with macros in a sense, so it would presumably be too disruptive to
be considered for any pythonic Python. OTOH, it might be an interesting path for some variations
to converge under one sort-of-pythonic (given the python decorator as precedent)
source-transformation markup methodology. (I'm just looking for reaction to the
general idea, not specific syntax problems).

Regards,
Bengt Richter