[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generic Arithmetic
Date: Tue, 14 May 1996 11:40:50 -0400 (EDT)
From: david carlton <firstname.lastname@example.org>
On Tue, 14 May 96 00:05 EDT, Aubrey Jaffer <email@example.com> said:
> From: david carlton <firstname.lastname@example.org>
[ talking about the merits of generic arithmetic. ]
First, I should say that I'm _not_ proposing that Scheme actually
adopt a broader generic arithmetic system; I'm just saying that I'd be
annoyed if it were any narrower than it is and that I personally would
find it convenient for it to be broader though I can understand why
other people might think that that's a bad idea. Numerical systems
definitely become a lot trickier when you have a numerical lattice
instead of numerical tower, for example.
Your comments and those discussing efficiency of generic arithmetic
have made me realize that there is a need in this area, but that by
entering this subject via exceptions, we do not see this need clearly.
Like you, I spend a lot of time writing type dispatch (but not
overlaid on built-in procedures). For single argument type dispatch,
COND is reasonably concise and readable. But for multi-argument type
dispatch, nested CONDs are difficult to write, repetitive, and
confusing to modify. Using an exception system to specify type
dispatch seems a terribly baroque method, which brings in lots of
I wish we had a construct to encapsulate MULTI-ARGUMENT TYPE DISPATCH.
With such a construct:
* Compilers would be able to optimize dispatch fairly easily, without
* New numeric types could be introduced easily by redefining Scheme's
arithmetic operators to procedures which dispatch to the original
Scheme procedures for the original types, and to new code for new
* Macros could be written to provide a "methods" interface for Scheme
(built-in and new) data types.
* Being able to organize into a single procedure and close a
dispatching routine means that a compiler can optimize quite
aggressively this case (because no new methods will be added).
* If properties such as commutivity, left/right-associativity,
etc. were specified (or easily deduced) in the dispatch construct,
compilers would be able to optimize invocations of routines defined
I am sorry that I currently have no construct to offer for this