Marcin 'Qrczak' Kowalczyk <xxxxxx@knm.org.pl> writes: >> Okay, how about a library function: >> >> (define NaN (lambda() > > What advantage it has over a literal syntax? A NaN must have a literal > syntax anyway for output. Says who? Ok, it's probably a good idea. But nearly every Lisp and Scheme system has lots of objects that have writable but non-readable objects. Why should we want to create new types of tokens? That's craziness; the genius of the language is that we *don't* just extend the lexical character of the language to solve every new problem. (nan) is a good, solid, schemey way of dealing. #<nan> or whatever other grot, is not. And '(nan)' is shorter to type! Nothing prevents the writer from writing '(nan)' when told to output a NaN value too. But I'm sure you are now going to insist that it must be a single token. Why? We don't have a way to write continuation objects (for nearly every Scheme); that hasn't blocked the success of the language.
