[r6rs-discuss] R6 counterproposal

From: Thomas Lord <lord>
Date: Fri, 25 May 2007 12:09:30 -0700

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
features:


* 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
  value.

  "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,
  locatives.

  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
  as is found in Python, Lua, Javascript, Self, and so forth.



* 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
  values).

  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
  SRFIs.

  Module systems should be removed from the language, and ....

  Record systems should be .....

  You get the idea.


Thanks,
-t
Received on Fri May 25 2007 - 15:09:30 UTC