From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: New module system option :duplicates Date: 12 Mar 2003 16:05:00 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <87fzpsocbn.fsf@zagadka.ping.de> References: <87ptp3b5ak.fsf@zagadka.ping.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1047482483 19155 80.91.224.249 (12 Mar 2003 15:21:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 12 Mar 2003 15:21:23 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 12 16:21:18 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 18t82g-0004yK-00 for ; Wed, 12 Mar 2003 16:21:18 +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 18t82B-0007S5-00 for guile-devel@m.gmane.org; Wed, 12 Mar 2003 10:20:47 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18t7r8-0003nV-00 for guile-devel@gnu.org; Wed, 12 Mar 2003 10:09:22 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18t7oQ-0001sM-00 for guile-devel@gnu.org; Wed, 12 Mar 2003 10:06:42 -0500 Original-Received: from [129.217.163.6] (helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10.13) id 18t7mw-0000f1-00 for guile-devel@gnu.org; Wed, 12 Mar 2003 10:05:02 -0500 Original-Received: (qmail 26637 invoked by uid 1000); 12 Mar 2003 15:05:00 -0000 Original-To: djurfeldt@nada.kth.se In-Reply-To: Original-Lines: 154 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:2072 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2072 Mikael Djurfeldt writes: > If I haven't missed something, there are no problems with implementing > the current :duplicate option within the framework of new-model.text. Ok, that is the important bit as far as I am concerned. I'm still a bit wary about merge-generics from a language design point of view, but since it is an optional feature and we can support it in the future, I don't see a problem with offering it. > > [...] > > Such a model can easily support an interface like > > > > (define-module (foo) > > :use-module (blarg) > > :use-module ((bar) :select (mumble)) ; explicitely import mumble > > :use-module (baz) ; also imports mumble > > ; but only implicitely and > > ; since we have an explicit > > ; mumble, we won't see it > > :duplicates check) ; we expect no explicit duplicates > > Do I understand this correctly in that you suggest having bindings > with two "priority levels": "explicitly imported" = priority 1, > "implicitly imported" = priority 2. Only duplicate bindings with > priority 1 causes an error (:duplicates check) while other duplicate > pairs are resolved (at lookup-time) according to :duplicates first > with precedence for the binding of higher priority. Yes. > Hmm... Isn't this a little conceptually complex? Yeah, perhaps. ADA and VHDL do a similar thing with their "potential visibility" and their rules are indeed complex (I only reall about know VHDL, tho). After getting my head around the concept of potential visibility, however, I find it quite intuitive. When there are no conflicts, the rules are still very simple: you get to see every imported binding. However, when there are conflicts and you have asked explicitely for one of the conflicting bindings, you get the one you asked for. But we can probably implement this as an option in the module system as well, if we ever want to. That's the basic motivation behind new-model.text: modules should be able to implement a very rich and hackable behavior without the compiler having to know about it. > What is the gain of differing between "potentially imported" and > "actually imported"? It seems like a nice thing to be able to > determine the set of imported bindings when the module is > constructed. Yes, the effect will mostly be as if the module has been fixed after the 'define-module' statement, but while 'define-module' does its thing, incrementally importing one set of bindings after the other, not all information is available to resolve conflicts. The distinction between potentially imported and actually imported bindings in there to support such a incremental construction of a module in a natural way. Also, it defines what happens when you interactively change a module with 'use-modules', say. > Is the aim to support the current "lazy binding" technique used in > guile-tcltk? No, only to support lazy resolution of naming conflicts. In effect, a conflict is only then reported when it actually matters and when no resultion has been specified yet by the user. One fundamental concept in new-model.text is that a module never shrinks: once a binding has been found in a module, it can not be removed or changed. The potentially imported bindings would not be known by the compiler and as such, could still be removed and changed. Once the compiler asks for a binding and the module finds it among the potentially imported bindings, it must become 'actually' imported and can no longer change. Imagine an interactive session like guile> (use-modules (graphics 2d)) ; exports make-point guile> (use-modules (graphics 3d)) ; also exports make-point guile> (define p (make-point 0 0)) ERROR: 'make-point' is ambigous (in (graphics 2d) and (graphics 3d)). guile> (use-modules ((graphics 2d) :select (make-point))) guile> (define p (make-point 0 0)) # Only when make-point is actually used, we check for conflicts. Once a resolution is provided by the user, the session can continue. > Regarding the transition: What about making "check" the default > duplicates handler but provide a form which the user can put in > his/her .guile if he/she want to be backward compatible? > > (default-module-duplicates-handler 'last) I'd rather have this the other way around. Making '(warn last)' the default is OK, I'd say, since it does not stop code from working. > > ;; merge 2d-x and 3d-x into x. Likewise for y and z. > > (merge-prefix-generics (2d 3d) x y z) > > > > This is not much more tedious than ":duplicates merge-generics" but > > much more precise. No unexpected mergings are done and the remaining > > collisions of non-generics are also dealt with in a useful way. > > I like this. However, I'd like to provide this facility *in addition* > to giving the license to merge. Yes, very good. > Given that we already had `define-extended-generic' I've now added > > (define-extended-generics (x y z) #:prefix (2d: 3d:)) > > I chose this form because I have the feeling that we might want to > have other additional ways of selecting the generics in the future. > > Please tell me if you like your `merge-prefix-generics' better or if > you have a third suggestion. 'define-extended-generics' is better. > > Also, merging of generic functions might be a useful thing to do, even > > without using the module system explicitely. > > Yes. We've had `define-extended-generic' for a while, but I have not > come to documenting it in NEWS. I'll fix my old sins ASAP. Ahh! :-) I didn't know about it indeed... > > Does this make sense, Mikael? > > Given my recent commits, I guess I have to return the question. Do > you think my recent additions make sense? Yep, very much. > The default duplicates handler is: > > (replace warn-override-core check) I would like to have a default that works exactly like what we have now, with additional warnings. That way, code does not suddenly stop working, but people get warnings and are 'encouraged' to fix their code anyway. Would (warn last) work? People can still use (default-module-duplicates-handler ...). -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel