Mark H Weaver wrote: >In Scheme terminology, an expression of the form (quote <datum>) is a >literal.
Ah, sorry, I see your usage now. R6RS speaks of that kind of expression being a "literal expression". (Elsewhere it uses "literal" in the sense I was using it, referring to the readable representation of an object.) Section 5.10 "Storage model" says "It is desirable for constants (i.e. the values of literal expressions) to reside in read-only memory.". So in the Scheme model whatever that <datum> in the expression is it's a "constant". Of course, that's in the RnRS view of expressions that ignores the homoiconic representation. It's assuming that these "constants" will always be "literal" in the sense I was using. >Where does it say in the documentation that this is allowed? It doesn't: as far as I can see it doesn't document that aspect of the language at all. It would be nice if it did. >To my mind, Guile documents itself as Scheme plus extensions, I thought the documentation was attempting to document the language that Guile implements per se. It doesn't generally just refer to RnRS for the language definition; it actually tells you most of what it could have referred to RnRS for. For example, it fully describes tail recursion, without any reference to RnRS. It's good that it does this, and it would be good for it to be more complete in the areas such as this where it's lacking. So maybe I got the wrong impression of the documentation's role. As the documentation doesn't describe expressions in the RnRS character-based way, I got the impression that Guile had not necessarily adopted that restriction. As it doesn't describe expressions in the homoiconic way either, I interpreted it as silent on the issue, making experimentation appropriate to determine the intent. Maybe the documentation should have a note about its relationship to the Scheme language definition: say which things it tries to be authoritative about. >cannot determine what extensions you can depend on by experiment. Fair point, and I'm not bitter about my experiment turning out to have this limited applicability. >Consider this: you serialize an object to one file, and then the same >object to a second file. Now you load them both in from a different >Guile session. How can the Guile loader know whether these two objects >should have the same identity or be distinct? That's an interesting case, and I suppose I wouldn't expect that to preserve identity. I also wouldn't expect you to serialise an I/O port. But the case I'm concerned about is a standalone script, being compiled as a whole, and the objects it's setting up at compile time are made of ordinary data. I think some of our difference of opinion here comes because you're mainly thinking of the compiler as something to apply to modules, so you expect to deal with many compiled files in one session, whereas I'm thinking about compilation of a program as a whole. Your viewpoint is the more general. >For example, how do you correctly serialize a procedure produced by >make-counter? Assuming we're only serialising it to one file, it shouldn't be any more difficult than my test case with a mutable pair. The procedure object needs to contain a reference to the body expression and a reference to the lexical environment that it closed over. The lexical environment contains the binding of the symbol "n" to a variable, which contains some current numeric value. That variable is the basic mutable item whose identity needs to be maintained through serialisation. If we have multiple procedures generated by make-counter, they'll have distinct variables, and therefore distinct lexical environments, and therefore be distinct procedures, though they'll share bodies. The only part of this that looks at all difficult to me is that you may have compiled the function body down to VM code, which is not exactly a normal Lisp object and needs its own serialisation arrangements. Presumably you already have that solved in order to compile code that contains function definitions. Aside from that it's all ordinary Lisp objects that look totally serialisable. What do you think is the difficult part? -zefram
