[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.