leppie wrote:
> > For example, #i#xf/c is inexact.
>
> So what is #e#b+inf.0 ?
>
> IMO (beside it being absurd), this is not a valid number, and should be an
> error.
This has nothing to do with the radix. #e#b+inf.0
is no more problematic than the #e+inf.0 notation.
#e+inf.0 is certainly absurd, but we are talking
about a document that contains a fair amount of
absurdity. In my opinion, #e+inf.0 is merely one
manifestation of a far more significant absurdity:
the complexity of the entire lexical syntax.
I agree that #e+inf.0 should be an error, and I
believe that it *is* an error in approximately the
R5RS sense, which is to say it has unspecified
behavior with respect to the R6RS: Implementations
of the R6RS are not required to raise an exception
when they encounter #e+inf.0 as a lexical token,
because it is clearly generated by the lexical
syntax and there is no clarifying prose to suggest
that it is illegal or should raise an exception;
at the same time, implementations should be allowed
to raise an exception because #e+inf.0 makes no sense.
It's sort of like the R6RS's mandates with respect
to the use of transcoders with variable-width encoding
in connection with set-position or input/output ports:
what the R6RS says doesn't make a whole lot of sense,
so the behavior is highly implementation-dependent.
Here's a quick survey of how the few extant
implementations of the R6RS behave:
#i#xf/c #e+inf.0 #e+nan.0
Ikarus 0.0.2 1.25 exception exception
Larceny 0.961 1.25 +inf.0 +nan.0
ypsilon 0.9.5 exception exception exception
MzScheme 4.0.2 exception exception exception
In my opinion, the behaviors exhibited by Ikarus and
Larceny in the table above both conform to the R6RS,
but the behavior exhibited by ypsilon and MzScheme
in the #i#xf/c column is a clear violation of the
R6RS.
Will
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
