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>
instead of the useless
#<queue:0xDEADBEEF>
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.)
As for your second stool, general customization requires the ability
to have what happens at run time affect what happens at read time,
specifically the compiler's read time. This immediately drags in
eval-when with all its horrors. (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 have what I think is a better idea for extending the lexical syntax
(R5RS: "lexical structure") that will not introduce such pain. There will
be a posting on that, for now I'll just say that it would be possible
to make
#queue (1 7 111 10)
both the read- and the print-syntax for queues.
--
John Cowan [email protected] http://ccil.org/~cowan
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
--Gerald Holton
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
