This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx> 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.