Email list hosting service & mailing list manager

Should we drop curly-foo, etc.? David A. Wheeler (27 Sep 2012 21:31 UTC)
Re: Should we drop curly-foo, etc.? John Cowan (27 Sep 2012 21:32 UTC)

Should we drop curly-foo, etc.? David A. Wheeler 27 Sep 2012 21:31 UTC

Now that we have marker, should we drop the specification's text about curly-foo and standard readers?

IE, should we drop this text?:
=====================
The “standard readers” are the datum reader used by the REPL, the datum readers defined by the relevant Scheme standards (such as “read” and where applicable “get-datum”), and the readers used to load user-supplied code as defined by the relevant Scheme standards (e.g., the reader used by “load” and module-loading mechanisms for user code). The standard readers are curly-infix enabled if the standard readers are curly-infix readers.

An implementation of this SRFI must have its standard readers be curly-infix enabled. We encourage implementations’ default invocation to have their standard readers be curly-infix enabled, but this is not required. If the standard readers are not curly-infix enabled in an implementation’s default invocation, then if it has a default command line invocation line using some command “foo”, the implementation must provide an alternative command “curly-foo” (the command prefixed with “curly-”) in which its standard readers are curly-infix enabled. In addition, if the implementation is invokable as a graphical user interface (GUI), it must provide a documented means to ensure that its standard readers are curly-infix enabled on startup.
=====================

--- David A. Wheeler