[pypy-svn] r3797 - pypy/trunk/doc/funding

[lac at codespeak.net]

Author: lac
Date: Tue Apr  6 07:34:47 2004
New Revision: 3797

Modified:
   pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
fix more typos, nits, and basically fiddle because I am that kind of person.


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	Tue Apr  6 07:34:47 2004
@@ -9,7 +9,7 @@
 the programmers that use them ("language users").  
 Even the implementations of Open Source dynamic languages have
 non-flexible designs crafted by a small group of developers.
-(This has always been a 'given'.  The language designers, or designers,
+(This has always been a 'given'.  The language designer, or designers,
 make certain tradeoffs in their language implementation, and the
 language users are stuck with what was decided, even if it does not
 suit their particular needs.)
@@ -64,6 +64,7 @@
 
 * choice of memory and threading model 
 * choice of speed vs. memory trade-offs
+* plugable adaptive implementations of various HL types, e.g. dictionaries
 * distributed/parallel execution (SMP or Networked)
 * orthogonal persistence
 * pervasive security support
@@ -81,10 +82,13 @@
 passing all unit-tests of the current reference C-implementation that are 
 relevant to the new one. At least 90% of existing unit tests will be directly
 applicable.[*]_ Moreover, we will be able to add techniques such as JIT compilation
-without making the interpreter more complex. Thus we will get speed increases of
+without making the interpreter more complex. Not only will we thus
+produce a more easily-understood optimising compiler, of particular
+interest to educators, but we will also get speed increases of
 2-10 times over the reference C-implementation. We expect algorithmic code to 
 run at least at 50% of the speed of pure, optimized C code.
 
+
 .. [*] The reference C-implementation contains some tests that depend on
    implementation details. The exact line between a language feature and an
    implementation detail might at times be hard to draw precisely, but in any
@@ -100,8 +104,8 @@
 researched attempt at achieving modularity for interpreters. They have
 not been tried on something as large as Python but in the context of
 Domain-Specific Languages (DSLs). However, the approach is hard
-to relate to for programmers accustomed to more conventional Object-Oriented 
-(OO) programming and requires sophisticated partial evaluation to remove the
+for programmers accustomed to more conventional Object-Oriented (OO) 
+Programming to grasp, and requires sophisticated partial evaluation to remove the
 monadic overhead. On the positive side, monad transformers are powerful enough
 to modularize continuation passing, exceptions and other control flow aspects.
 
@@ -117,9 +121,10 @@
 taken e.g. for the Scheme (Scheme 48) [K97]_ and the Smalltalk
 (Squeak) [IKM97]_ languages. These approaches are typically based on
 translation from high-level source code (or parsed source code) into
-C. Obtaining in this way an interpreter comparable with the current C
-Python implementation would be within current state of the art; but note
-that our approach differs in three respects (as explained in more
+C.  It would be possible within this current state of the art to obtain 
+an interpreter comparable with the current C
+Python implementation in functionality; but note
+that our approach already differs in three respects (as explained in more
 details in the section *Beyond the State of the Art*): what we will translate is a dynamically loaded
 and initialized program state instead of the static source code; the translator
 works by abstract interpretation (also known as symbolic interpretation),
@@ -154,7 +159,7 @@
   possible to leverage its benefits to the new language. This path is
   not only much shorter than designing a complete custom JIT compiler,
   but it is also easier to maintain and evolve. This idea is explored
-  for the Self virtual machine in [WAU99]_, building on top of it
+  for the Self virtual machine in [WAU99]_, built on top of 
   experimental Java and Smalltalk implementations .  As pointed out in
   that paper, some source language features may not match any of the
   target virtual machine features. When this issue arises, we are left