The current draft SRFI specification includes the procedure (enable-curly-infix), for implementations that don't enable curly-infix by default.
One early comment we got back was, "The global modification of the the built-in reader seems a bit drastic; I suspect many implementations will find this hard to support." Of course, we *do* want it globally available, but some implementations may have trouble doing a global *modification* once they're running. I'm thinking that maybe what we want is to require that either (1) implementations enable them by default, or (2) if they have a command line invocation "foo", they *must* support an alternative command "curly-foo" that enables curly-infix in the default datum reader (such as read), REPL, and loaders (such as load). That way, an implementation doesn't have to support *changing* them once they're going. (enable-curly-infix) could then be downgraded to a "should" or "may" instead of a "must" (I'm leaning towards "should"). Comments? --- David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/readable-discuss
