[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: arithmetic issues
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.