[pypy-svn] r3635 - in pypy/trunk/doc/funding: . negotiations
arigo at codespeak.net
arigo at codespeak.net
Thu Apr 1 16:08:52 CEST 2004
Author: arigo
Date: Thu Apr 1 16:08:52 2004
New Revision: 3635
Modified:
pypy/trunk/doc/funding/B1.0_objectives.txt
pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt
Log:
- Upgraded the section "Beyond the state of the art",
with explicit focus on Theoretical concepts,
How we do it, and Distribution outside python.
- Added one line to the responses for "interesting
outside python".
Modified: pypy/trunk/doc/funding/B1.0_objectives.txt
==============================================================================
--- pypy/trunk/doc/funding/B1.0_objectives.txt (original)
+++ pypy/trunk/doc/funding/B1.0_objectives.txt Thu Apr 1 16:08:52 2004
@@ -176,21 +176,44 @@
Beyond State of The Art
-----------------------------
-Our architecture is based on Object Spaces and translation. The
-interpreter's main dispatch loop handles control flow and supporting
-data structures (frame stack, bytecode objects...); each individual
-operation on objects is dispatched to the Object Space.
+Theoretical concepts
+++++++++++++++++++++
+
+* We present a novel interpreter architecture based on the separation
+ between Bytecode interpretation and **Object Spaces.** The former, i.e.
+ the interpreter's main dispatch loop, handles control flow and supporting
+ data structures (frame stack, bytecode objects...), while each individual
+ operation on objects is dispatched to the Object Space. In effect,
+ an Object Space explicitely captures the notion of "object library".
+
+* Object Spaces simultaneously capture the notion of "abstract domains":
+ indeed, building on this architecture, **abstract interpretation** based
+ on the *same* Bytecode interpreter with a different Object Space gives
+ us unprecedented power and simplicity for all kind of source analysis
+ tools. In particular, this is a new way to efficiently close the gap
+ between a Very High-Level Language (VHLL) and low-level code, including
+ for advanced JIT compilers.
+
+* Many aspects of the interpreter are not fixed in all their details within
+ the interpreter source: they are **translation aspects,** i.e. they are
+ weaved into the low-level translation of our VHLL source by the process of
+ translating it into a low-level equivalent. This allows low-level aspects
+ like multithreading, memory management, and continuation management to be
+ kept orthogonal from the rest of the source.
+
+
+Interpreter modularity
+++++++++++++++++++++++
Object Spaces, in contrast to monadic interpreters, will allow
-customization with OO techniques, as they encapsulate the object
-operation semantics, creation and global state of all objects. As
-mentioned above, monad transformers can be used to modularize
-continuation passing, exceptions and other control flow aspects. We
-expect to encapsulate each of those either in Object Spaces, in the interpreter
-loop, or as aspects of the translation process (which would then generate
-for example continuation-passing code).
+customization with OO techniques. They encapsulate the object
+operation semantics, creation and global state of all objects.
+As mentioned above, monad transformers have been used to
+modularize continuation passing, exceptions and other control flow
+aspects; the theoretical solution we provide offers a more practical
+and scalable approach to the modularization of these aspects.
-This latter point is in contrast to the related work previously cited:
+In contrast to the related work previously cited,
we don't expect to encode a fixed single interpreter in all its details in a
subset of our VHLL (Python). We plan to exploit the flexibility and abstraction
gained by using the VHLL and -- most importantly -- the indirectness of
@@ -210,7 +233,11 @@
In summary, we will explore for each feature and extension how to best
implement it by separation of concerns: either in OO-customized Object
Spaces, or in the core or in modules to be translated, or as a pluggable
-behavior of the translation itself.
+behaviour of the translation itself.
+
+
+Translation aspects
++++++++++++++++++++
The front-end of the translator itself will be innovative in that it is
based on abstract (symbolic) interpretation. The translation of code
@@ -219,12 +246,12 @@
plugging a custom Object Space. This turns the Object Space operations
into the semantics units of translation as well, leveraging the coherence
of our architecture and gaining independence from surface issues including
-the details of the bytecode itself.
+the details of the syntax or of the bytecode itself.
Moreover, we can use the full dynamism of Python at system definition time,
i.e. when PyPy loads, until we reach a "stable-and-ready" state that the
translator can freeze into a snapshot containing exactly the features and
-modules that we need. In previous work, the translator only operated on the
-static source code.
+modules that we need. In previous work, the translator generally operated
+on the static source code.
During the translation process, weaving custom aspects will be done mainly
as intermediate stages, while the customizable back-end generates low-level
@@ -249,11 +276,32 @@
of (or in addition to) the normal C instructions that would be the
direct translation.
-Finally we expect to develop automatic interpreter build tools that allow
+
+Distribution
+++++++++++++
+
+We expect to develop automatic interpreter build tools that allow
choices about aspects, modifications and extensions to be made by the
language user, and that enable advanced programmers to develop and
integrate their own aspects and extensions to the language.
+We believe that ours is a practical and scalable approach to interpreter
+modularity, applicable to any language, from general to domain-specific ones.
+The PyPy implementation should quickly reach the large user base of the
+current, industrial-strength Python, and could eventually form the fundation
+of the "next generation" Python implemention commonly refered to as
+Python3000. The efforts will be focused on actively reaching out non-Python
+communities, based on:
+
+* the build tools to generate customized versions of Python, attractive to
+ a larger industrial base which is currently outside the scope of VHLLs
+ for reasons like performance, configurability, or end-user device resources;
+
+* the framework of PyPy's source code, reusable to implement other
+ general or domain-specific languages;
+
+* the theoretical approach and solutions that we publish.
+
----------------------------------------------
**References**
Modified: pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt
==============================================================================
--- pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt (original)
+++ pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt Thu Apr 1 16:08:52 2004
@@ -103,9 +103,10 @@
Multithreading and memory mangagement models which today
have to be manually coded all over a language implementation.
-The practical implementation leverages an *industrial-strength* language
-implementation (Python) thus connecting the STREP to a large user base.
-It is possible that PyPy will form the fundation of the "next
+Each one of these notions is interesting beyond the scope of Python.
+Moreover, the practical implementation leverages an *industrial-strength*
+language implementation (Python) thus connecting the STREP to a large user
+base. It is possible that PyPy will form the fundation of the "next
generation" Python implemention commonly refered to as Python3000. Once
we have reports and specific versions of PyPy we will reach out to
non-python communities (see WP14_).
More information about the Pypy-commit
mailing list