Ray Dillinger scripsit: > 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.
I have no trouble with these. > 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. string->number already does this, if given two arguments. > new library procedure: inf, which takes a symbol '+ or '- > and returns an infinity having the matching sign. That's fine, but you end up with two numbers with no external representation. If you type "(inf '+)" to the REPL, what should it print? > 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. It's not about it appearing in source code, it's about it appearing in results. > 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. That won't work. "(NaN)" is not the external representation of the number NaN, but of a list with a single element. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck [EMAIL PROTECTED] soup the rest of your life. --Groucho _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
