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: Unintentional conflict in define-immutable-type? Date: Fri, 27 Nov 2015 16:21:49 -0500 Message-ID: <87mvtzuoia.fsf@netris.org> References: <87610yfwes.fsf@trouble.defaultvalue.org> <87io4xivcv.fsf@netris.org> <87h9keeq9l.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448659357 2524 80.91.229.3 (27 Nov 2015 21:22:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 21:22:37 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 27 22:22:25 2015 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 1a2QTI-0003Tf-SO for guile-devel@m.gmane.org; Fri, 27 Nov 2015 22:22:25 +0100 Original-Received: from localhost ([::1]:58558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2QTL-0002TK-PI for guile-devel@m.gmane.org; Fri, 27 Nov 2015 16:22:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2QTI-0002T1-I4 for guile-devel@gnu.org; Fri, 27 Nov 2015 16:22:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2QTH-0001F4-P7 for guile-devel@gnu.org; Fri, 27 Nov 2015 16:22:24 -0500 Original-Received: from world.peace.net ([50.252.239.5]:34724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2QTC-0001DC-RY; Fri, 27 Nov 2015 16:22:18 -0500 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=jojen) by world.peace.net with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1a2QSv-0005Yw-DC; Fri, 27 Nov 2015 16:22:01 -0500 In-Reply-To: <87h9keeq9l.fsf@trouble.defaultvalue.org> (Rob Browning's message of "Sat, 21 Nov 2015 20:12:22 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.252.239.5 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:18069 Archived-At: Rob Browning writes: > Mark H Weaver writes: > >> I believe you are mistaken about that. Looking at both the code and the >> expansion of your 'define-immutable-record-type' form above, I see no >> evidence that is bound to anything by it. > > I imagine it's actually goops that's doing it. > > Try using "define-immutable-type " and then add a (display > <>). I did, and I found that <> was unbound. However, I see now that if GOOPS is loaded, <> does indeed become bound to a class. I find this a bit unsettling to be honest, but I stand corrected. Thanks :) > That's what prompted my original post, I thought it might be handy to be > able to use define-immutable-type (and the other record definitions) to > create "normal" goops class names. > > So that you can have: > > (define-immutable-type foo ...) > (define-method (bar (x )) ...) You can do this if you pick a different name for the constructor. However, I agree that it would be nice to allow the class to be named and the constructor to be named foo. The first idea that comes to mind is to provide an optional extension to the 'define-record-type' and 'define-immutable-record-type' syntax to explicitly give the name of the class. Then you could name the RTD something like :foo and still name the class . > instead of only supporting: > > (define-immutable-type ...) > (define-method (bar (x <>)) ...) > > Of course you can always just: > > (define <>) > > afterward, but that's not quite right. I guess that wouldn't work. After (define-immutable-type ...), it's important that remain bound to the RTD in the module where 'define-immutable-type' was evaluated. The other procedures defined by 'define-immutable-type' refer to and rely on it being bound to the RTD. Mark