I think at this point we are looking, not at the actual problem,
which is that numeric syntax is too complex, but at a symptom of
the problem, which is that we don't know what to do with a syntax
that seems to be "accidentally" correct.
I know it's far too late to do this in R6, but I propose,
for R7 or independent lisp-1 designers:
All numbers in base 10. Decimals and scientific notation
allowed, other extensions not allowed.
Inexact if there is a decimal in the number or the number
is expressed in scientific notation; otherwise exact.
Where this is inconvenient, people can write it the
other way and bracket it with existing procedures to
convert exact->inexact or inexact->exact.
new library procedure: radix - takes a string and a radix,
returns a number which is the interpretation of the string
as a number given that radix. Can be used the same way to
bracket odd-radixed numbers represented as strings in source
code.
new library procedure: inf, which takes a symbol '+ or '-
and returns an infinity having the matching sign.
new library procedure: NaN, which takes no arguments and returns
the value #nan.0 . I do not see incremental value in having a
direct write syntax for this value, because I can think of very
few situations in which it would appear in useful source code.
And if you need it in source code, you can write "(NaN)" with
fewer characters than "+nan.0" anyway. "(NaN)" might also be used
as a printing syntax/external representation if that doesn't
muddy things too much.
new library syntax: (hexadecimal <string>) for (radix <string> 16)
new library syntax: (boolean <string>) for (radix <string> 2)
new library syntax: (octal <string>) for (radix <string> 8)
I may start the ball rolling by writing this up as a SRFI.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
