Incomprensible – constructores redundantes en programación genérica aditiva.

La sección 2.4.3 proporciona un ejemplo detallado de cómo la despacho por etiquetas se puede usar para escribir código genérico que también se pueda extender fácilmente:

Suponiendo la existencia de put op type item y put op type para registrar y recuperar operaciones específicas del tipo desde una tabla, dos clientes, uno trabajando con números complejos a través de coordenadas rectangulares y otro utilizando coordenadas polares, definen sus propias versiones de selectores (real-part, imag-part, magnitude y angle) y constructores (make-from-real-imag y make-from-mag-ang) y registran todos estos en la tabla. Las versiones genéricas de esos selectores luego eligen la implementación correcta desde la tabla, basándose en una etiqueta que los constructores adjuntan sistemáticamente a los números complejos en el momento de la construcción.

En cuanto a los constructores, estos 4 están registrados:

(define (install-rectangular-package)
  ...
  (put 'make-from-real-imag 'rectangular
       (lambda (x y) (tag (make-from-real-imag x y))))
  (put 'make-from-mag-ang 'rectangular
       (lambda (r a) (tag (make-from-mag-ang r a))))
  ...
  'done)

(define (install-polar-package)
  ...
  (put 'make-from-real-imag 'polar
       (lambda (x y) (tag (make-from-real-imag x y))))
  (put 'make-from-mag-ang 'polar
       (lambda (r a) (tag (make-from-mag-ang r a))))
  ...
  'done)

pero solo se exportan 2:

(define (make-from-real-imag x y)
    ((get 'make-from-real-imag 'rectangular) x y))
(define (make-from-mag-ang r a)
    ((get 'make-from-mag-ang 'polar) r a))

Veo que no es necesario exportar los otros dos, porque por ejemplo, usar make-from-real-imag desde uno u otro módulo afecta un detalle de implementación (cómo se almacena el número complejo) y nada más.

Pero mi punto es, ¿por qué definir esos constructores en primer lugar si son fundamentalmente redundantes?