[r6rs-discuss] R6 counterproposal
jays at panix.com
Fri May 25 16:53:11 EDT 2007
On Fri, 25 May 2007, Thomas Lord <lord at emf.net> wrote:
> R6 should be completely different from the current draft,
> in my opinion.
> The addition of a few, parsimoniously chosen features
> eliminates the need for almost everything that is new
> in the R6 draft. Nearly *ALL* of the new hacks could
> be done as SRFIs, if only R6 would add these few OPTIONAL
Yes. Let us keep Scheme Scheme.
> * Reader Extensibility
> The Scheme reader should have something *similar* to
> Common Lisp's reader tables and reader hooks. It should
> be possible, for example, to program the reader to
> parse (for example) Lua code or Python Code. It should be
> possible to program the reader to parse XML or (lax) HTML.
> * First Class Reflection of Types and Environments
> ** There should be a new atomic type, TYPE?
> There should be one unique (under EQV?) type value
> for each value type recognized by the implementation.
> Each value type should have exactly one TYPE. Programs
> should be able to create new type values. Programs
> should be able to box arbitrary values under a given
> TYPE. Access (reading and writing contents of) a
> value should require access to the corresponding TYPE
> "Records" should not be in R6. Given the simpler proposal
> of TYPE objects, records can be implemented in a SRFI.
> ** There should be first class environments and locatives
> Programs should be able to capture, at run-time, an
> associative data structure which encapsulates all of the
> variables within the lexical scope of the point of capture.
> It should be possible to modify the binding of any variable
> and to add or remove bindings in the innermost frame of
> a first-class environment. (Of course, EVAL should accept
> these environments as a parameter.)
> Of course, it must be a statically decidable property
> of each non-top-level lexical scope whether or not
> environments representing that scope are ever captured,
> whether captured environments escape, and whether and how
> non-escaping environments might be modified.
> Programs should also be able to construct run-time binding
> contours which "share variables" in ways which are not
> statically apparent in any of the source code -- hence,
> These features are straightforward completion of the idea of
> having environments present in the semantics of the
> language. They fit naturally into all of the classic
> techniques for implementing interpreters.
> These features admit a straightforward implementation of
> many different kinds of module system.
> These features provide Scheme with the (efficient, natural)
> basis of a dynamic, prototype-based object system such
> * FEXPRs (Normal Order Functions) and First Class Closures
> LAMBDA defines applicative-order procedures.
> FLAMBDA should define normal-order procedures. The
> evaluation rule for applications of an FLAMBDA procedure
> are explained below.
> A first-class CLOSURE value encapsulates a first-class
> environment, a source form, a parameters sepecification,
> and a designation as either an FLAMBDA or a LAMBDA
> procedure. (CLOSURE values are a subset of PROCEDURE
> When an FLAMBDA is used in a procedure call:
> (<exp0> <exp1> <exp2> ....)
> where <exp0> evaluates to an FLAMBDA procedure
> The FLAMBDA body is evaluated, with parameters bound,
> as if it were an ordinary lambda that had been invoked:
> (<exp0> (make-closure (the-environment) `(,lambda () ,'<exp1>))
> (make-closure (the-environment) `(,lambda () ,'<exp1>))
> .... )
> Thus, normal-order evaluation is supported -- but it is not
> "all" that FLAMBDA can do.
> Macros should be removed from the language, and promoted via
> Module systems should be removed from the language, and ....
> Record systems should be .....
> You get the idea.
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
More information about the r6rs-discuss