From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - accessors, methods and generics Date: Tue, 05 Mar 2013 19:28:39 -0500 Message-ID: <877gllcqx4.fsf@tines.lan> References: <20130221195139.59f41d13@capac> <20130222201110.0a9e715c@capac> <20130305203027.184e7a66@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362529744 27989 80.91.229.3 (6 Mar 2013 00:29:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Mar 2013 00:29:04 +0000 (UTC) Cc: guile-devel@gnu.org To: David Pirotte Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Mar 06 01:29:29 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UD2Ea-0004dk-27 for guile-devel@m.gmane.org; Wed, 06 Mar 2013 01:29:28 +0100 Original-Received: from localhost ([::1]:54741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD2EE-0008Ao-B6 for guile-devel@m.gmane.org; Tue, 05 Mar 2013 19:29:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:40997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD2E8-0008AC-5b for guile-devel@gnu.org; Tue, 05 Mar 2013 19:29:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UD2E6-00040x-9E for guile-devel@gnu.org; Tue, 05 Mar 2013 19:29:00 -0500 Original-Received: from world.peace.net ([96.39.62.75]:51868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UD2E6-00040t-4h for guile-devel@gnu.org; Tue, 05 Mar 2013 19:28:58 -0500 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UD2Dy-0004Nq-8t; Tue, 05 Mar 2013 19:28:50 -0500 In-Reply-To: <20130305203027.184e7a66@capac> (David Pirotte's message of "Tue, 5 Mar 2013 20:30:27 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15868 Archived-At: Hi David, David Pirotte writes: > no, what needlessly complicates things is the unfortunate decision of guilers to > mix goops with the module system: you do not want any [by far inferior] module > system to interfere with clos/goops. [...] [...] > if at least guile designers and goops implementors would have provided a 'switch' > so that we could ask that any and all goops related stuff being in a single name > space available 'anywhere' at all time [such as guile core functionality is], No, guile core functionality is *not* in a single name space. It is in the (guile) module. There are several problems with your proposal. First of all, there's no syntactic distinction between generic function calls and ordinary procedure calls. For that matter, in Scheme the operator position of a procedure call is evaluated in the same way as any other expression. So, in the context of Scheme, what you're suggesting essentially boils down to this: every *variable* lookup would have to first look in your "single name space" before looking anywhere else. But let's set this (very serious) problem aside for the moment. I want to explain the reason why I believe a "single name space" is fundamentally a bad idea, even if generic function calls *could* be syntactically distinguished. Suppose Bob uses GOOPS to write a component for drawing things on a text display using curses. He defines a 'draw' generic function, and add several methods to it, including methods to render all of the standard Scheme types such as lists, vectors, and strings. Now suppose that Alice uses GOOPS to write a component that also defines a 'draw' generic function, but with very different semantics. Alice adds her own methods to 'draw' the standard Scheme types. The module system allows these two components to coexist in the same system without those two 'draw' generic functions from interfering with each other. This in turn allows hackers to use short names such as "draw", "ref", "x", etc, without fear of unintended conflicts. What's worse: under your proposal, if conflicts arose between modules, there's no easy way to fix it. You'd have to rename the generic functions in one of the components to avoid the conflict. In practice, people experienced with such a system would eventually learn that they must pick long variable names and cross their fingers, just as people did in the bad old days of dynamically-scoped variables. So that's the argument in favor of the module system. What's the argument on the other side? Apparently, it's that you find it inconvenient to define your interfaces (generic functions) in a separate module and to import that module in all of your other modules. To my mind, the arguments in favor of the module system are *far* more compelling than those of the other side. I'm sorry that you chose to characterize our position as "religion". Personally, I found that very disrespectful. Mark