On Mon, Aug 24, 2009 at 9:43 AM, Harold Ancell <[email protected]> wrote: > At 07:51 AM 8/24/2009, David Rush wrote: > One additional wrinkle to this division would be to carefully and > no doubt over time add to small Scheme optional? primitives that > allow reasonably efficient implementation of important features > of large Scheme. > > I gather that the IETF's experience with its requirement for working > code suggests that the future Scheme language definition process > would benefit from such a requirement to guide its evolution. That > would then ideally allow one to take a small Scheme with the above > suggested efficiency extensions and add reference libraries to > produce a not terribly painful to use large Scheme. >
A small scheme intended for "educational" use is unlikely to fully expose the underlying data. At the workshop, I proposed a third working group for a "bootstrap" scheme that would eliminate the need for working in a separate language for building the runtime. Prescheme would serve as an initial template. As I see it, this standard would add another guaranteed space optimization property roughly stated as: A programming unit satisfying a specified set of conditions implying that the set of instantiated variables and objects can be statically determined would incur no further space overhead during execution. I am using the term "instantiated variables" to differentiate between multiple instances of a given closure due to recursion. Having dispensed with garbage collection overhead, we also need to be able to dispense with dynamic typing overhead: A programming unit satisfying a specified set of conditions implying that the data representations of variables and objects can be statically determined would incur no further space overhead during execution. This would require a facility for specifying arbitrary data representations down to individual bits. If we want to be able to implement our own closures or FFI, we need to be able to turn data into applicable objects. There are several parts to this: the data to be made applicable, a specification of its input, the in which to place the input, the specification of its output, and where to place its continuation. To avoid dependence on machine details, the notion of invoking the data can be specified in relation to the implementations semantics. Finally, we would need to be able to obtain a list of memory roots and their data representations. As demonstrated by Kelsey, providing these guarantees does not have to reduce the language to C. Retaining that extra expressive power, however, almost certainly means that the properties to be verified cannot be purely syntactic. Lynn _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
