[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: number crunching
- To: firstname.lastname@example.org (David A. Moon)
- Subject: Re: number crunching
- From: Bob Kerns <email@example.com>
- Date: Mon, 05 Oct 92 21:00:13 -0400
- Cc: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>, firstname.lastname@example.org
- In-reply-to: Your message of "Mon, 05 Oct 92 16:42:21 EDT." <9210052037.AA06015@cambridge.apple.com>
Date: Mon, 05 Oct 92 16:42:21 EDT
From: email@example.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.