From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: New module system option :duplicates Date: 08 Mar 2003 09:38:57 -0500 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: References: <87ptp3b5ak.fsf@zagadka.ping.de> <87el5jb3gp.fsf@zagadka.ping.de> <87zno7w1xk.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047134347 24201 80.91.224.249 (8 Mar 2003 14:39:07 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2003 14:39:07 +0000 (UTC) Cc: Marius Vollmer Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 08 15:39:03 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18rfTb-0006Hz-00 for ; Sat, 08 Mar 2003 15:39:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18rfTx-0005Hg-04 for guile-devel@m.gmane.org; Sat, 08 Mar 2003 09:39:25 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18rfTc-0005Ed-00 for guile-devel@gnu.org; Sat, 08 Mar 2003 09:39:04 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18rfTb-0005DW-00 for guile-devel@gnu.org; Sat, 08 Mar 2003 09:39:04 -0500 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18rfTb-00053B-00 for guile-devel@gnu.org; Sat, 08 Mar 2003 09:39:03 -0500 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 77EE6861; Sat, 8 Mar 2003 09:38:57 -0500 (EST) Original-To: Rob Browning In-Reply-To: <87zno7w1xk.fsf@raven.i.defaultvalue.org> Original-Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-cc: guile-devel@gnu.org Original-cc: djurfeldt@nada.kth.se X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Developers list for Guile, the GNU extensibility library List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:2055 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2055 That's what I just thought about too. i.e. I'd guess that merging (open ) and (open ) would be just fine, but what about merging (open ) from module-1 with (open ) from module-2? Personally, I'd probably want to see an error in the latter case, but the question is in general, how would a "conflict" be defined? If one thinks of all procedures as generics, then adding a method with specializers that does not conflict is different from one that does conflict. But, the definition of conflict has two interesting wrinkles: If one defines two methods, and one is more specialized than the other, but they are not disjoint, then the second definition will modify the result of using the first definitions generic function. For example: guile> (use-modules (oop goops)) guile> (define-method (f (a )) (+ a 1)) guile> (f 1) 2 guile> (f 1.0) 2.0 guile> (define-method (f (a )) (+ a 2)) guile> (f 1) 3 guile> (f 1.0) 2.0 Here, the methods do not 'conflict' in the sense of specifying different behaviors for the same provided specializers, but they are not disjoint either. The proposal of an extended generic which finds methods from several generics seems nice. In the case that Mikael talked about, it seemed the methods were all disjoint, so this works cleanly. With non-disjoint methods, perhaps an error should be signalled, or this should be treated the same way as an export-export conflict. Mikael's proposal of merging methods but not modifying values also avoids another nasty issue: define-generic overwrites previous generic function values and non-procedure values, but not previous simple procedures. So if either module uses define-generic, there is no way to merge the values into a single generic function. All that said, it troubles me somewhat to have a new extended-generic type. Is it possible to just construct a new generic function add all the methods from each of the generics in the modules to the new generic function and be done with special treatment? Finally, I did not understand This implies that x in (math 2D-vectors) can see the methods of x in (my-module) and vice versa, while x in (math 2D-vectors) doesn't see the methods of x in (math 3D-vectors), thus preserving modularity. Why would any method in (math 2D-vectors), or use of gf x, ever see methods defined in my-module? This seems like a clear modularity violation, but I suspect I'm confused. I think a core underlying issue is that define-method is a mutator on the gf (perhaps it needs a ! :-): guile> f #< f (2)> guile> (generic-function-methods f) (#< () 80902b0> #< () 8090310>) guile> (define-method (f (a )) (+ a 3)) guile> (generic-function-methods f) (#< () 80905a0> #< () 80902b0> #< () 8090310>) So, perhaps _always_ exporting generic functions by creating a new generic and adding the methods is the proper path. Normally modules only export procedures, and they are immutable - I would expect calling set! on the exported name to rebind the name in the using module, and not affect the used module. Exporting variables of course can lead to mutation, but this is far clearer and less likely to lead to unexpected trouble. Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel