Refining terminology
Hi folks, i have just started to write some documentation about PyPy's bytecode interpreter (only the overview chapter in fact see http://codespeak.net/pypy/index.cgi?doc/interpreter.html ). And i realized that i'd like to push to refine the terminology we are using throughout the PyPy documentation and our presentations. For starters, i think that it does not make sense to fight against the common notion of an "interpreter" refering to the whole thing (our bytecode interpreter + objectspace). If we want to refer to the "pure" thing, we should thus talk of the "bytecode interpreter". Usually refering to our (Python) Interpreter then really means StdObjSpace + the bytecode interpreter. Other wording issues are the various "times", "levels", "phases" and "passes" we are talking about. I think we desparately need pictures to support a clear and consistent terminology and make it more obvious to everyone. This may become even more important when we'll go for a JIT-compiler interweaving levels as well as compile- and runtimes some more. Well, maybe we should just go through the effort of creating a "glossary" containing the basic vocabulary we are using for describing what PyPy does and how it works. And i think we should try to reuse common VM/Compiler terminology, even refering to Wikipedia and other public resources, to make it easier for non-Python/PyPy crowds to understand what we are doing. I guess that some of you may think that it is only real working code that matters (i know some do :-). But i think this is not true. Communicating the concepts is and has always been a major issue of the whole project. Any opinions or feedback (also from people just following the project's progress)? cheers, holger
On Tue, 12 Jul 2005 12:19:33 +0200 holger krekel <hpk@trillke.net> wrote:
Hi folks,
i have just started to write some documentation about PyPy's bytecode interpreter (only the overview chapter in fact see http://codespeak.net/pypy/index.cgi?doc/interpreter.html ). And i realized that i'd like to push to refine the terminology we are using throughout the PyPy documentation and our presentations.
# ... cut ...
Well, maybe we should just go through the effort of creating a "glossary" containing the basic vocabulary we are using for describing what PyPy does and how it works. And i think we should try to reuse common VM/Compiler terminology, even refering to Wikipedia and other public resources, to make it easier for non-Python/PyPy crowds to understand what we are doing.
I guess that some of you may think that it is only real working code that matters (i know some do :-). But i think this is not true. Communicating the concepts is and has always been a major issue of the whole project.
Any opinions or feedback (also from people just following the project's progress)?
From the lurker POV this is indeed very important. Just to give a real-life example, the computational reflection field trudged slowly just because nobody had the same definition for what a "meta-object" really meant. I'm +1 for the creation of a pypy-abstraction glossary. Even though tedious, I believe this task must be an **inside-job** == performed by the core-dev team. OTOH, validate such glossary is up-to-us neopypytes ;o) best regards, senra
Hi Holger, On Tue, Jul 12, 2005 at 12:19:33PM +0200, holger krekel wrote:
Well, maybe we should just go through the effort of creating a "glossary" containing the basic vocabulary we are using for describing what PyPy does and how it works.
Yes, it makes sense. We already discussed this at least once, but didn't bring it to a more concrete conclusion. Maybe we should just start a pypy/documentation/glossary.txt and start linking to/from it. A bientot, Armin.
Hi Armin, On Tue, Jul 12, 2005 at 18:42 +0200, Armin Rigo wrote:
On Tue, Jul 12, 2005 at 12:19:33PM +0200, holger krekel wrote:
Well, maybe we should just go through the effort of creating a "glossary" containing the basic vocabulary we are using for describing what PyPy does and how it works.
Yes, it makes sense. We already discussed this at least once, but didn't bring it to a more concrete conclusion. Maybe we should just start a pypy/documentation/glossary.txt and start linking to/from it.
Good idea, first thing i would like to know what exactly "PBC access sets", "family of classes" and a few other things are :-) More seriously, i think that the increasing size of PyPy's documentation makes it more difficult to choose the right link targets. So i am not sure we should intend to link to the glossary unless the glossary itself back-points to relevant sections. cheers, holger
Hi Holger, On Tue, Jul 12, 2005 at 06:50:05PM +0200, holger krekel wrote:
Good idea, first thing i would like to know what exactly "PBC access sets", "family of classes" and a few other things are :-)
:-) This is actually a good idea, though it can only point back to the relevant section; no actual information should be in the glossary for this kind of entry. But I think that it still makes sense to have them in the glossary. A bientot, Armin.
participants (3)
-
Armin Rigo -
holger krekel -
Rodrigo Dias Arruda Senra