[r6rs-discuss] R6 counterproposal

[Jay Sulzberger]

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

Yes.  Let us keep Scheme Scheme.

oo--JS.



>
>
> * 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
>
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss at lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>