Re: New module system option :duplicates

[Mikael Djurfeldt]

Rob Browning <address@hidden> writes:

> Hmm.  Though I haven't thought carefully about it yet, that still
> feels like somewhat a modularity violation to me.
>
> Say you have a working module called (math-frob) that defines/uses
> some generic-function, say "do-fancy-+", that at the time (foo random)
> was designed only had a method for ((x <number>) (y <number>))
> arguments.
>
> Then say someone writes module (bar) that defines do-fancy-+ for ((x
> <integer>) (y <integer>)) arguments, but does it in a way that's not
> compatibile with the do-fancy-+ usages in (foo random).  If someone
> does
>
>   (use-modules (foo random))
>   (use-modules (bar))
>
> then is (foo random) now broken, and if so, is that to be expected/OK?
> i.e. does this just fall under the "well don't do that then" category?

I'd like to add to what I wrote in my previous reply that what you
describe above is not a new kind of problem introduced by the
:merge-generics possibility.  Consider the following code which is
realizable in old version of Guile and in CLOS:

(define-module (baz)
  :export (do-fancy-+))

(define-generic do-fancy-+)

(define-module (foo random)
  :use-module (baz))

(define-method (do-fancy-+ (x <integer>) (y <integer>)) ...)

(define-module (bar)
  :use-module (baz))

(define-method (do-fancy-+ (x <integer>) (y <integer>)) ...)

The Kiczales paper suggest design principles and a certain disciplin
which can be used to avoid these kind of problems.