Re: [pypy-dev] question about core implementation language
"Edward K. Ream" <edream@tds.net> wrote:
I have started some prototyping in Python, and I now remember some words of Guido, that Python isn't specially well suited for such a task. I admit, there is some truth in it.
I don't understand Guido's comment. I personally think Python is absolutely superb for any prototyping endeavor.
Perhaps I am being dense, but the fact that Python doesn't have feature x of language y seems totally a non-issue. You want a switch statement? Write a psyco_switch function (in Python, of course). Ditto for anything else your heart desires. Eventually _everything_ that generates code is going to become assembly code, but that is no problem at all for any compiler.
Perhaps I am confusing levels of discussion or implementation. However, the way I see it, the most important thing is to do experimentation with algorithms. To do that, the essential thing is to compare various ways of doing things, at as high a level as possible. In other words, a psyco_switch routine provides a good enough model for the task at hand. Ditto for any other construct you want.
Actually, for experimentation (perhaps leading to inspiration) I wouldn't necessarily confine myself to any particular level of implementation or design or whatever. I would simply blast away using whatever language tools appear to be most useful. Armin has talked about doing high-level work with discovering list optimizations, for example. I don't understand what the lack of a Python switch statement has to do with such matters.
In short, I would hardly bother at all with questions of the level at which Python is modeling some implementation. I would use whatever works in Python and worry about mapping that back to a final implementation only after it is clear that Python in Python will be a big win. At that time we will have lots more data, energy and incentive to do the needed grunt work. Until then, I wouldn't let implementation problems get in the way of invention.
Just my $0.02.
Edward
_______________________________________________ pypy-dev mailing list pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
I think the point is that Python as a language provides absolutely no access to the machine internals. You can't examine memory contents, registers, I/O bus or call code directly. As part of the bootstrap process the following four functions should probably be added to the interperter (either as builtin functions or a module): GetMemoryFromOS() ReturnMemouryToOS() Peek() Poke() ANd probably: get/putRegister() callCode() Other than that, everything could (eventually) be written in Python. --------------------------------------- Get your free e-mail address @zworg.com
Hello Logistix, On Sun, Jan 19, 2003 at 06:23:03PM -0500, logistix wrote:
I think the point is that Python as a language provides absolutely no access to the machine internals. You can't examine memory contents, registers, I/O bus or call code directly.
It doesn't matter. It has to be built on the top of *some* basic abstractions, but these don't have to be as low-level as that. The interpreter proper can be written in pure Python, and only specific "non-borrowing" implementations need more (e.g. to implement a list as an array of PyObject* with a length field, or to implement the time.time() function by calling a Posix- or Windows-specific OS function). Ideally, we can provide various implementations of the same concept upon various lower-level concepts. We should not stick to one given low-level abstraction. We might for example give two "list" implementations, one based on "memory block" objects that correspond closely to malloc()ed blocks, and one as a Lisp-like chained list based on couples (2-tuples). In all implementations we should somehow express what other abstractions this implementation depends on. The final code emitters can then choose which implementation(s) they will use depending on what low-level abstractions are provided by the target language (e.g. targetting C, the "memory block" objects are ideal; for Java we might reuse its built-in concept of array). A bientot, Armin.
participants (2)
-
Armin Rigo -
logistix