Re: number crunching

[Bob Kerns <rwk@crl.dec.com>]

    Date: Mon, 05 Oct 92 16:42:21 EDT
    From: moon@cambridge.apple.com (David A. Moon)
    
    But then, my own opinion is that 
    the trig functions in chapter 14, complex numbers,
    and floating point numbers should all be removed from
    the Dylan language.

This seems reasonable to me, too.  But again, things like this
should be standardized in parallel with the language.

I think one reason we couldn't agree on subsets in ANSI
is that we were going about it backwards:  Standardize
on everything, and then remove stuff.  I think standardizing
on a core as language, and separatly standanrdizing a set of
fairly independent additional modules, is a lot more likely
to succeed.  Plus you don't have to finish them all at
exactly the same time; you can point to the core, when
it's standardized, as a concrete standard.  And you don't
have this atificial deadline of "No, the language is
frozen", when you want to add something, so long as it
doesn't require changes to the core.

    Perhaps you and I are actually in agreement there; my reasoning is
    that if one isn't going to do a serious implementation of
    floating-point, one shouldn't do a half-baked job, instead one should
    not even claim to try.

I'm not sure I agree with this.  If you mean that you
shouldn't produce implementations with unknown or excessive
error bounds, weird incontinuities, unspecified branch cuts,
and other gotchas, then I agree.  It's better to let the
user up front know he would be  wasting his time, instead
of sucking him in.

But if you mean that it's not worth doing an implementation
that's not fully as efficient as it could be, but is otherwise
well behaved, then I don't think I agree.