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

[lac at codespeak.net]

Author: lac
Date: Sun Apr  4 14:25:46 2004
New Revision: 3735

Modified:
   pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
fiddly bits, with one sentence that bothered me, and fixing typo, and not much


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	Sun Apr  4 14:25:46 2004
@@ -6,12 +6,17 @@
 ---------------------------
 
 Current language implementations are static and hard to modify by
-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.  While
-designing a good programming language is no easy task, often
-application developers seek more support and configurability of their
-language. This is especially the case for the rising number of
+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,
+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.)
+
+With a new flexible architecture, it is now possible to give 
+application developers more flexibility and configurability in their
+preferred language. This is especially the case for the rising number of
 specialized runtime environments where small memory footprints,
 concurrency or real-time features are essential.
 
@@ -20,7 +25,7 @@
 suitable, so that VHLL are usually implemented by introducing a
 bytecode and interpretation level, resulting in a loss of performance.
 This is in contrast to lower-level languages such as C, which offer
-performance but greatly decrease productivity.
+better performance but greatly decrease productivity.
 
 The architectures of current interpreter implementations are a
 compromise between initial simplicity, Unix-style portability and
@@ -37,11 +42,11 @@
 compiler, adding a significant amount of code and complexity and further
 impairing the flexibility. [S03]_
 
-Consequently, application developers are often left with bad choices
-not only regarding productivity versus performance, but they have to work
-around hard-wired characteristics built into the languages. Instead they
-would like to adapt and configure a VHLL to suit their needs while at the same
-time developing on top of a custom but standardized language offering both
+Consequently, application developers are often left with bad choices -
+not only regarding productivity versus performance, but also involving the
+hard-wired characteristics built into the languages. They would prefer
+to adapt and configure a VHLL to suit their needs while at the same
+time developing on top of a customized but standard language offering both
 productivity and performance.
 
 Quantified specific objective
@@ -185,7 +190,7 @@
   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".
+  an Object Space explicitly captures the notion of "object library".
 
 * Object Spaces simultaneously capture the notion of "abstract domains":
   indeed, building on this architecture, **abstract interpretation** based