Discussion:
[Larceny-users] wrongly extended nan? finite? infinite? functions
Marco Maggi
2009-01-23 10:09:45 UTC
Permalink
In R6RS the NAN?, FINITE?, INFINITE?
functions take argument X, which is
defined to be a real number[1].

The implementation in Larceny-5896
accepts complex numbers, too. Is this
to be considered a violation of what
is written in section "5.6 Safety":

|As defined by this document, the
|Scheme programming language is safe
|in the following sense: The execution
|of a safe top-level program cannot go
|so badly wrong as to crash or to
|continue to execute while behaving in
|ways that are inconsistent with the
|semantics described in this document,
|unless an exception is raised.

?

(I prefer the extended implementation,
though.)

[1]http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-2.html#node_toc_node_sec_6.2
--
Marco Maggi
William D Clinger
2009-01-23 15:23:31 UTC
Permalink
Post by Marco Maggi
In R6RS the NAN?, FINITE?, INFINITE?
functions take argument X, which is
defined to be a real number[1].
The implementation in Larceny-5896
accepts complex numbers, too.
That's a bug in Larceny, although I think it
might fall under the category of "Larceny does
not conform to known errors in the R6RS" or
"Larceny does not enforce deliberate weaknesses
and restrictions whose primary purpose is to
justify additional features." [1]
Post by Marco Maggi
Is this to be considered a violation of what
Yes. IMO, it's a very minor violation because it
only affects programs that do both of the following:

1. The program passes an illegal argument to
one of the nan?, finite?, or infinite?
procedures.

2. The program defines an exception handler
that is designed to catch that exception
and to continue operation of the program.

That non-conformance is already documented [1]:
"Larceny doesn't always raise a violation exception
when the R6RS says it must, and doesn't always create
the precise condition object the R6RS says it must
create when it raises those exceptions. Larceny raises
almost all of the required exceptions, however, and is
always memory-safe on programs that are said to be safe
as defined by the R6RS."
Post by Marco Maggi
(I prefer the extended implementation, though.)
Me, too, so I don't know whether we'll fix it,
especially since we already have an established
policy of less-than-total conformance on this
kind of thing. I'll log it as a trivial defect,
though, because I was unaware of this particular
non-conformance.

Will


[1] https://trac.ccs.neu.edu/trac/larceny/wiki/DargoMode

Loading...