At 08:41 PM 2/23/99 -0500, David T. Lewis wrote:
>Some further explanation of the behavior of Float>>exp in Squeak:
>
>The Float>>exp method in Squeak is based on the behavior of exp() in
>the C runtime library. The Squeak VM (at least on Unix) assumes that
>the underlying C library behaves reasonably for the boundary conditions
>of negative infinity and positive infinity. In fact, however,
>implementations of the C library vary.
[snip]

That seems to be a receipt for endless errors without resolution.

I wonder if a useful approach in Squeak might be to leverage off the work of
another body of user supported code so that their improvements are
automatically gained by Squeak.  What comes to mind is GNU or Linux C or
C++, or even Lisp.  There might be licensing problems with this.

Another approach might be to have a Squeak C interface library that uses the
C runtime library but corrects for anomalies between the interface and the C
runtime.  One could fairly easily determine once what the anomalies are with
a C runtime, and then handle them.

With a library test suite, I think the anomalies with a C runtime could be
quickly identified and easily handled.

I have no experience programming on UNIX.  I seem to remember seeing this
same problem in almost every UNIX application I ported to DOS, and in
portable implementations of other languages (CLisp is the one I remember).
I suspect a good starting point for a solution is to see how others have
handled it.  Could those of you who have experience with portability
problems comment on  what solution you've seen that was most effective?

The macros that implemented this consistency were horrendously ugly stuff,
but once you saw the pattern, adding a new configuration was pretty straight
forward and there didn't appear to be any runtime costs.


>Certainly it is possible to add tests for the boundary conditions
>in the Squeak VM code, albeit at some cost of complexity and
>performance. But first the question would be, what is the "right
>thing to do" here? Should Squeak expect the underlying system
>libraries to be correct, or should it attempt to compensate for
>behavior of the runtime libraries in the interest of consistent
>Squeak behavior? My own inclination would be to leave Squeak
>well enough alone, but possibly document the dependency on the
>underlying libraries in the class documentation.
[snip]

I think this just moves the problem to the documentation.

--
Richard A. Harmon          "The only good zombie is a dead zombie"
harmonra at webname.com           E. G. McCarthy