From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Kovacsics_R=C3=B3bert?= Newsgroups: gmane.lisp.guile.user Subject: Re: Modules and GOOPS Date: Fri, 29 Jul 2016 18:00:00 +0100 Message-ID: References: <20160728181425.5f167237@capac> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1469811655 31024 80.91.229.3 (29 Jul 2016 17:00:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 17:00:55 +0000 (UTC) Cc: guile-user@gnu.org To: David Pirotte Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jul 29 19:00:50 2016 Return-path: Envelope-to: guile-user@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 1bTB9V-0006i4-TR for guile-user@m.gmane.org; Fri, 29 Jul 2016 19:00:50 +0200 Original-Received: from localhost ([::1]:60662 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTB9P-00046A-SB for guile-user@m.gmane.org; Fri, 29 Jul 2016 13:00:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTB94-000464-J8 for guile-user@gnu.org; Fri, 29 Jul 2016 13:00:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTB93-0002w4-FB for guile-user@gnu.org; Fri, 29 Jul 2016 13:00:22 -0400 Original-Received: from mail-ua0-x235.google.com ([2607:f8b0:400c:c08::235]:33874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTB93-0002vr-B5 for guile-user@gnu.org; Fri, 29 Jul 2016 13:00:21 -0400 Original-Received: by mail-ua0-x235.google.com with SMTP id 35so66023529uap.1 for ; Fri, 29 Jul 2016 10:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Wseg2U1OBKiRvTLlnvemzNJ1FtfYZa8cObPn/W3LR0=; b=JTDeZnpPpZ6lc/qc1xmWyy1iVy2VoYJd7uDSKRy97zXOX6mjvLxBNUgsFrAKIWhB5/ qZd53cRW4ELeO0dki1hSYcammhTxtlX/is+LqMY0QW0OkQiagSbbFS0yOay06qK6/TVx F/tPT+WjvPbaykcDQkVqmnjo4oCG2hrsRyb8P266d+eqAEc86RsnvLPcYMla7kc/JylO tO6FtgF0mtALLuONnc3qgocvQAcfnf71OpW1WavGwb5Kn7blddTIrIxR1ywTO0WajCEI W49Notxch/eIBDkV6OVPuMDU3Jf39OfMaO1SDFO38o0qToDK3oXFXmfagb6HoS/Bje19 WdjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Wseg2U1OBKiRvTLlnvemzNJ1FtfYZa8cObPn/W3LR0=; b=h/pmo7ANH2J9tteJrXnfySAmp/BAbj1oT1iIDxv4NpeXGSxOtxSbDCcbIFBv8CVz9W 1U1fJuhgaLSQRzMgMsDChmfvQgZLnh6uHAfVDPrjtyQTWQwMsbc9XmBx6/rpIfudzzNd 18Ns2QaqqlRcaZiTPG3W26SkcZC1+q2j8UFA5GL1WPEC9uXjEF3J0ddpW2NLxrKBkDCS eBhaNnki2k2fSvnO4/246LT6N2XIFhsBea1z0fV1m5Xud53iTrDroZJqvse0hqtRPDUH 3wJs7C4YSl8gohD4FCKM1/XJvh9MK7ik2etHUuWydUpkDdwBjz/Iunmd1Qxaa873Av6R UkKg== X-Gm-Message-State: AEkoousdpHEJNKuwSPG56XcHTtUVjX2p+pCwa2JeEowIRLBU+4P1zNa8nkRH7um3wgPm+xgjIEN/wh68sgNebw== X-Received: by 10.159.41.164 with SMTP id s33mr18871071uas.146.1469811620321; Fri, 29 Jul 2016 10:00:20 -0700 (PDT) Original-Received: by 10.103.100.195 with HTTP; Fri, 29 Jul 2016 10:00:00 -0700 (PDT) In-Reply-To: <20160728181425.5f167237@capac> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::235 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:12807 Archived-At: First, thank you for your detailed answer! On 28 July 2016 at 22:14, David Pirotte wrote: > First, generic functions are 'containers', that are not associated, and do not > pertain to any class. does not have a generic function x: Thank you, I am still thinking in Java terms at the moment. > Then unlike you've been told by others, I do not recommend to define generic > function, they are just 'containers', the system creates them for you and it is an > error [not implemented by Guile] to redefine a generic function. With the last in > mind, manually defining GF will work if you play with a couple of your own modules, > but it will almost certainly fail for large system. So what is the right approach when I'm implementing textbook data structures (rather than want to use the given ones, for learning reasons) and want to implement a set. On this set, I want to write a method "closure" that computes all the elements of the set given a function on the set elements, such that for any call to the function with an element of the set, the result will also be in the set. This is the same code for all implementation, but depends on implementation specific code such as "contains?" and "add". Then I want to implement different sets, e.g. red-black trees, AVL trees, etc. The plan was something like this, but I think I may be trying to achieve it wrong, or at least the unidiomatic way: ; = (define-module (sets set) #:use-module (oop goops) #:export ( add ... closure)) (define-class ()) (define-generic add) ... (define-method (closure (set ) (function )) ... contains? ... add ... ) ; = (define-module (sets red-black-tree) #:use-module (oop goops) #:use-module (sets set) #:export ()) (define-class ()) (define-method (add (tree )) ...) ; = ... Code to exercise methods ... > But if you do so, define generic functions manually, then I recommend do it in > another module. So I could move the add, etc, methods out into another module, if that is the way to do it, but I need them, because without having them, Guile will complain with "unbound variable: add". But this is a very classes-contain-methods approach and given what you said, makes me think that I'm doing this wrong thing.