As Marc says, it's wiser not to `write` any special syntax until there's
an established convention for how to configure `write`. It's easy to add
custom writing later, but harder to preclude it once it's established.
There probably never will be a way to configure `write` because backward compat, though there may be something like `object->string+` that can be configured by adding new methods to the generic function. (Trailing `+` is a convention for generic functions.)
#!chezscheme ; switch to R6RS + Chez Scheme extensions
#!fold-case ; symbols are case-insensitive in the rest of the file
#!no-fold-case ; symbols are case-sensitive in the rest of the file
Chicken has #ci and #cs for case-insensitive and case-sensitive. Larceny has these:
#!r7rs ; implies #!no-fold-case, enables R7RS syntax
#!r6rs ; implies #!no-fold-case, negates other flags
#!r5rs ; implies #!fold-case, enables R7RS syntax
#!err5rs ; enables R7RS/R6RS syntax with extensions
#!larceny ; implies #!no-fold-case and #!err5rs
>> That said, I expect that this SRFI (if it goes all the way to final) will go on the ballot for R7RS-large when notational issues come to be considered. So objections about not being RnRS-compatible arguably go away then.
> A possible way-out would be that SRFI 207 defines a SRFI 39 parameter,
> initially set to #f. When it is paramerized to #t, "write" and friends
> may use SRFI 207 in printing. This is still an incompatible extension
> to "write", but it wouldn't probably hurt much.
Implementing it in an existing Scheme would hurt a lot.
Yes, parameter objects would probably be a good way to configure
`write`. Common Lisp uses dynamic variables to control its printer (all
*variables* listed in <http://clhs.lisp.se/Body/c_printe.htm>), and
those are CL's equivalent to Scheme parameters. It works well.
I don't agree, actually. You can set your own default to output integers in hex because it makes most sense for your application, but then if you need writes that are guaranteed to output them in decimal (say), then you need to wrap each call in its own dynamic let / parameterize. It gets ugly fast.