[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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

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.