On 10 Sep 2009, at 5:25 am, John Cowan wrote: > Brian Harvey scripsit: > >> I have no argument with the details of the notation, but could you >> please provide some explanation for why you think this belongs in >> Small Scheme? As you point out, it solves a limited class of >> problems, > > I should rather say that it provides a imperfect solution to a rather > general problem: how to construct things.
Yes. There's a line to be drawn (somewhere) about what objects can be represented in textual s-expressions, and which can only exist in memory. Closures have a good reason to perhaps be memory-only; we write Scheme code in s-expressions that makes them, drawing on a dynamic context. We could perhaps serialise them with some sort of syntax like this: #c<((x 1) (y 2) (z 3)) (lambda (a b c) (+ a b c x y z))> ...but the ability to do so would constrain implementations to keep source code around at run time, and to be able to compile or eval source code read in from streams, so we avoid making that part of the core. However, vectors have very little reason to be memory-only, as their natural in-memory representation straightforwardly maps to a textual representation and back: by the very definition of the vector API, it should be easy to convert to and from the vector syntax, unlike closures. So the question is, what to do about structures, which seem to fall slightly on the edge? They do have a natural representation, as they consist of a bunch of named slots with other values in, so not too different from a vector. But, unlike a vector, they also (potentially) have some measure of hidden internals, where a user API to whatever we're using the structure for might not necesssarily expose everything. So I'd say we ought to provide a basic automatic read/write syntax for them, but then offer the potential to override that to produce semantic-level representations for them in libraries that use structures to hide state. And yet also have a "pure-read"/"pure-write" pair that perform reading and writing purely in terms of defined syntax, with no invoking of user-defined readers/writers, for use in making those crucial debugging dumps, or for writing data to be transmitted to and from untrusted users, where we don't want so much arbitrary code being executed when we read, etc. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
