[Ecls-list] [PATCH] Improve floating-point exception handling.

[Gabriel Dos Reis]

On Tue, Jun 2, 2009 at 9:05 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> On Tue, Jun 2, 2009 at 3:53 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>> Yes, it would be useful for people to get a way choose IEEE-754 over
>> whatever CL thinks is best for them.
>
> Gabriel, sometimes it is comfortable and easy to adopt rant style, but
> there are many issues to consider: reading, writing, operations,
> switching on and off.

Sorry if you took it as rant -- it wasn't meant to be.

I however do confess being occasionally annoyed by
having to be blocked by CL spec from using more
useful semantics provided by the hosting systems, e.g.
IEEE-754 semantics for example.  I appreciate very much CL
systems which recognize the fact that lots of things have happened
way after CL spec was written, e.g. ECL has threads, SBCL
makes it easier to use IEEE-754 semantics if one wishes.

> I am not saying it will not be done, but this is work that the CL
> specification already did for a particular choice (no IEEE-754
> "special" numbers) and has to be redone for a different one.

As I said in my previous message, the CL work was done a long time
ago.  Since then, a lot has happened.  IEEE-754 is almost universally
available on modern computing devices, modern programming languages
(at least the ones that get revised) integrates IEEE-754.

>
> I personally appreciate the CL specification's consistency and would
> not like to just patch in NaNs and Infs, but rather get things right
> with as little disruption as possible. Probably SBCL's source code has
> something to say on this -- the manual gives no clue about their
> choices.

SBCL lets people construct NaNs, and starts being annoying only when
some operations are non-sensical (and rightly so).  For example,
SBCL lets me constructs infinities or NaNs through FFI without getting
mad -- unlike CLISP which I've stopped recommending for building OpenAxiom.
My hope is that ECL does not take the CLISP path on this.

Again, I never made a wish that ECL does not implement CL spec.  All
I suggested was a way for ECL to let people shoot themselves (from CL
spec perspective) with IEEE-754 semantics if they wanted to.  I suspect
that can only contribute to the useful of ECL.