On Tue, 2009-09-08 at 19:11 -0400, John Cowan wrote:
> Brian Mastenbrook scripsit:
>
> > Can you explain why a record type-specific printer procedure is a good
> > idea for Thing One? It seems to me that this approach falls between
> > two stools: it doesn't provide the guaranteed consistency for all
> > record types that standardizing a record print syntax would give, and
> > it doesn't provide the functionality or print-read consistency that a
> > general printer and reader customization would allow.
> It allows you, after loading and importing a queue component, to type
> > my-queue
> at the REPL prompt and get back the sensible
> #<queue:1,7,111,10>
> The trouble with CL's #S syntax (your first stool) is that it does not
> distinguish between slots users should initialize and those they should
> not, so it's possible to use #S to construct an object in a semantically
> invalid state. SRFI-9's BOA constructor eliminates that problem. (Though
> IWBNI you could have more than one constructor, nothing's perfect.)
I see your point, but I'm still liking the #S syntax, or some variant
thereof.
The ability to write and read back while in a semantically invalid
state is not a deficit: it can be very useful for, eg, debugging,
or for freezing a running image.
If you can actually write a program that *NEVER* puts the record
into a semantically invalid state (even between the third and
seventh step of a "simple" operation) then no, you'll never have
a need to save and restore that state. But I don't think that's
a reasonable demand to make.
Would it help to have the user specify a function that says when
something is, and is not, in a "valid" state? Are there any useful
points where the system, rather than the user code, could call that?
> (One of the many reasons I don't like
> low-level macros is that I believe that in principle a Scheme compiler
> should be possible that has no Scheme evaluation environment inside.)
I very emphatically do not share this belief.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
