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.