This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
mike@olan.com (Michael N. Livshin) writes: > Here is what I consider proper generic <-> module system interaction: > > (define-module (my-module) > #:use-modules (used1) (used2)) > > (define-generic-method some-known-generic (<myclass>...) > (do-stuff)) > > 1. In (my-module), some-known-generic has a method for <myclass> and > also has all the methods that were added to it in (used1) and (used2). > > 2. In (used1) or (used2), some-known-generic is *not* extended for <myclass>. While I agree that your suggestion is the most common sensical one, it seems to mix badly with some fundamental concepts in Scheme. In Scheme variables are bound to locations, nothing else. The module system is only responsible for supplying mappings between variables and locations. What we store in those locations is an entirely separate issue. If we have stored a generic function object in a variable in the module `used1' and the variable binding is exported, that means that whenever we add methods to the object, those methods will also be visible in the module `used1'. I guess the most reasonable way of dealing with this is that the module system is modified so that it not only copies bindings when exporting variables, but also makes a copy of the object stored in the location of the exported binding if that object is a generic function object. /mdj