SICP Exercise 2.82 coercion with multiple arguments

Exercise 2.82.  Show how to generalize apply-generic to handle coercion in the general case of multiple arguments. One strategy is to attempt to coerce all the arguments to the type of the first argument, then to the type of the second argument, and so on. Give an example of a situation where this strategy (and likewise the two-argument version given above) is not sufficiently general. (Hint: Consider the case where there are some suitable mixed-type operations present in the table that will not be tried.)



SOLUTION

 The code and tests are here.

Explanation of why this strategy is not sufficiently general

Let's assume that we need to support the following operation on three arguments. This function expects the first two arguments x and y to be of any types and the third one "factor" to be an ordinary number. It multiples c1 and c2 and scales the result to the value of factor.

Suppose the following implementations exist in the op-table for the operation "mul-and-scale":
complex, complex, scheme-number
rational, rational, scheme-number

And suppose that there is no procedure for the following:
complex, rational, scheme-number

 If apply-generic is called with the above permutation of arguments, it will first fail to find a procedure for it following which it will try to coerce it in the following ways:

complex, complex, complex
rational, rational, rational
scheme-number, scheme-number, scheme-number

None of these will work because there are no procedures for these permutations

But clearly, by coercing the 2nd argument only, this permutation can be coerced into the following permutation:

complex, complex, scheme-number for which which a procedure exists

Hence, the above is an example where this coercion strategy is not sufficiently general.

Comments

Post a Comment

Popular posts from this blog

SICP Exercise 4.18 a alternative strategy for interpreting internal definitions

Exercise 4.18.   Consider an alternative strategy for scanning out definitions that translates the example in the text to (lambda < vars >   (let ((u '*unassigned*)         (v '*unassigned*))     (let ((a < e1 >)           (b < e2 >))       (set! u a)       (set! v b))     < e3 >)) Here  a  and  b  are meant to represent new variable names, created by the interpreter, that do not appear in the user's program. Consider the  solve  procedure from section  3.5.4 : (define (solve f y0 dt)   (define y (integral (delay dy) y0 dt))   (define dy (stream-map f y))   y) Will this ...
Read more

SICP Exercise 3.11 make-account internal definitions with local state

Image
Exercise 3.11.    In section  3.2.3  we saw how the environment model described the behavior of procedures with local state. Now we have seen how internal definitions work. A typical message-passing procedure contains both of these aspects. Consider the bank account procedure of section  3.1.1 : (define (make-account balance)   (define (withdraw amount)     (if (>= balance amount)         (begin (set! balance (- balance amount))                balance)         "Insufficient funds"))   (define (deposit amount)     (set! balance (+ balance amount))     balance)   (define (dispatch m)     (cond...
Read more

SICP Exercise 3.13 make-cycle

Image
Exercise 3.13.    Consider the following  make-cycle  procedure, which uses the  last-pair  procedure defined in exercise  3.12 : (define (make-cycle x)   (set-cdr! (last-pair x) x)   x) Draw a box-and-pointer diagram that shows the structure  z  created by (define z (make-cycle (list 'a 'b 'c))) What happens if we try to compute  (last-pair z) ? SOLUTION The code is here: Exercise 3.13 make-cycle The box-and-pointer diagrams are here:
Read more