[pypy-svn] r18808 - pypy/dist/pypy/doc

[mwh at codespeak.net]

Author: mwh
Date: Thu Oct 20 22:33:39 2005
New Revision: 18808

Modified:
   pypy/dist/pypy/doc/draft-low-level-encapsulation.txt
Log:
more words for what will become D05.4.

i think that's enough translation aspects to be going on with.  probably each aspect 
deserves it's own section and a few more words each.

please read, fix typos etc.


Modified: pypy/dist/pypy/doc/draft-low-level-encapsulation.txt
==============================================================================
--- pypy/dist/pypy/doc/draft-low-level-encapsulation.txt	(original)
+++ pypy/dist/pypy/doc/draft-low-level-encapsulation.txt	Thu Oct 20 22:33:39 2005
@@ -2,6 +2,17 @@
       Encapsulating low-level implementation aspects
 ============================================================
 
+.. so this mentions the following aspects:
+    threading
+    gc policy
+    target platform
+    stacklessness
+    supporting multiple interpreter states
+    the thunk object space.
+
+   it does so in a very boring "here's one aspect, here's another"
+   sort of way.  this needs to change.  it's probably also too short.
+
 .. contents::
 .. sectnum::
 
@@ -46,13 +57,10 @@
 Of course, this is not the only aspect that can be so decided a
 posteriori, during translation.
 
-.. [#] http://www.stackless.com
-
-
 Translation aspects
 ===============================================
 
-Our standard interpreter[#]_ is implemented at a very high level of
+Our standard interpreter [#]_ is implemented at a very high level of
 abstraction.  This has a number of happy consequences, among which is
 enabling the encapsulation of language aspects described in this
 document.  The implementation code simply makes no reference to memory
@@ -61,9 +69,6 @@
 decision to use reference counting is reflected tens or even hundreds of
 times in each C source file in the codebase.
 
-.. [#] "standard interpreter" in this context means the code which
-       implements the interpreter and the standard object space.
-
 As described in `...`_, producing a Python implementation from the
 source of our standard interpreter involves various stages: the
 initialization code is run, the resulting code is annotated, specialized
@@ -73,6 +78,8 @@
 involves writing a new backend -- still a significant task, but much
 much easier than writing a complete implementation of Python!
 
+.. _`...`: http://www.example.com
+
 Other aspects affect different levels, as their needs require.  The
 stackless modifications for instance are mostly implemented in the C
 backend but also change the low-level graphs in small ways.  The total
@@ -114,7 +121,42 @@
 
 PyPy will offer the opportunity to experiment with different models,
 although currently only offers a version with no thread support and
-another with a GIL-like model.
+another with a GIL-like model.  XXX Could speculatively waffle here
+easily enough.
 
+A final low-level aspect is that of memory management.  As mentioned
+above, CPython's decision to use a garbage collector based on
+reference counting is reflected throughout the source.  In the
+implementation code of PyPy, it is not, and in fact the standard
+interpreter can currently be compiled to use a reference counted
+scheme or Boehm's `garbage collector for C`_.
+
+.. _`garbage collector for C`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
+
+Another advantage of the aspect oriented approach shows itself most
+clearly with this memory management aspect: that of correctness.
+Although reference counting is a fairly simple scheme, writing code
+for CPython requires that the programmer make a large number of
+not-quite-trivial decisions about the refcounting code and experience
+suggests that mistakes will always creep in, leading to crashes or
+leaks.  While tools exist to help find these mistakes, it is surely
+better to not write the reference count manipulations at all and this
+is what PyPy's approach allows.  Writing the code that emits the
+correct reference count manipulations is surely harder than writing
+any one piece of explicit refcounting code, but once it's done and
+tested, you it just works without further effort.
+
+Possibly the most radical aspect to tinker with is the evaluation
+strategy.  The thunk object space wraps the standard object space to
+allow the production of "lazily computed objects", objects whose
+values are only calculated when needed, and to allow the global and
+total replacement of one object with another.  The thunk object space
+is mostly meant as an example of what our approach can acheive -- the
+combination of side-effects and lazy evaluation is not easy to
+understand.
+
+.. [#] "standard interpreter" in this context means the code which
+       implements the interpreter and the standard object space.
+
+.. [#] http://www.stackless.com
 
-.. _`...`: http://www.example.com