On 8/23/12, David A. Wheeler <dwhee...@dwheeler.com> wrote: > 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?
I'm leaning towards a "may". Sincerely, AmkG ------------------------------------------------------------------------------ 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
