Re: Generic Arithmetic

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   Date: Tue, 14 May 1996 11:40:50 -0400 (EDT)
   From: david carlton <carlton@math.mit.edu>

   On Tue, 14 May 96 00:05 EDT, Aubrey Jaffer <jaffer@martigny.ai.mit.edu> said:
   > From: david carlton <carlton@math.mit.edu>

   [ 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
other baggage.

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
   global analysis.

 * 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
   types.

 * 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
   using dispatch.

I am sorry that I currently have no construct to offer for this
purpose.