From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: fixes to goops + light structs + 'u' slots Date: Sun, 20 Apr 2008 12:46:43 +0200 Message-ID: References: <87zls1bdk6.fsf@gnu.org> <87fxtpwq0t.fsf@gnu.org> <66e540fe0804131209y6a3a1810i72a6ba048a7cb83b@mail.gmail.com> <66e540fe0804141516w1e44cfc6u5f756aaa579cb5b1@mail.gmail.com> <66e540fe0804191607q79ec54e2nb7832e1e7928b68b@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1208688694 3590 80.91.229.12 (20 Apr 2008 10:51:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Apr 2008 10:51:34 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , guile-devel@gnu.org To: mikael@djurfeldt.com Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 20 12:52:07 2008 connect(): Connection refused Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JnX9S-00087y-AO for guile-devel@m.gmane.org; Sun, 20 Apr 2008 12:52:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnX8m-0003Wp-SP for guile-devel@m.gmane.org; Sun, 20 Apr 2008 06:51:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JnX8i-0003VI-2p for guile-devel@gnu.org; Sun, 20 Apr 2008 06:51:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JnX8g-0003UE-Cp for guile-devel@gnu.org; Sun, 20 Apr 2008 06:51:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JnX8g-0003Ts-1W for guile-devel@gnu.org; Sun, 20 Apr 2008 06:51:18 -0400 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19] helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JnX8U-0000b1-FB; Sun, 20 Apr 2008 06:51:07 -0400 Original-Received: from localhost.localdomain (localhost [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 649396F1E; Sun, 20 Apr 2008 06:51:05 -0400 (EDT) Original-Received: from unquote (96.Red-83-44-188.dynamicIP.rima-tde.net [83.44.188.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id 6EE256F1D; Sun, 20 Apr 2008 06:51:02 -0400 (EDT) In-Reply-To: <66e540fe0804191607q79ec54e2nb7832e1e7928b68b@mail.gmail.com> (Mikael Djurfeldt's message of "Sun, 20 Apr 2008 01:07:39 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7177 Archived-At: Hi, On Sun 20 Apr 2008 01:07, "Mikael Djurfeldt" writes: > Well, apparently I'm the very author of this GC chain thing you are > talking to me about. The only thing I can say is that there was > probably a reason at the time to do this. The reason is simple: you need a class to know how to free an instance. If a class and all of its remaining instances are all unmarked and thus sweepable, we need to sweep instances before classes. The particular strategy for dealing with this (i.e. GC chains) is ugly, however. > In fact, and to be honest, I've never had the impression that structs > are good design either. They're not in many aspects (heavy/light/entity representations, tail args), but the fundamentals are OK I think: word-vectors that are interpreted by other word-vectors (denoted "vtables"). > The Right thing to do is probably to throw out structs and design new > GOOPS objects, something I wanted to do from the start. You might be right; OTOH we could just weed out those anachronistic parts of structs, and orthogonalize the struct interface, making structs contain the minimum necessary to support GOOPS objects and SRFI-9 records. > Also, I've seen your GOOPS todo. It's nice to see your willingness to > continue development on GOOPS. Unfortunately, I won't have the time > to help. Just don't be too quick to throw things out. ACK. I'll be mailing patches to the list, so if you have time, take a look and carp if things aren't going well. > Otherwise I think I should shut up. If it's for your own reasons, fine, but your insights are appreciated. > Oh, and please *don't* try to compile methods at macro expansion time. > GOOPS method compilation is based on the crazy idea to have one > compiled method per combination of argument types. The idea is that > this won't give you a combinatorial explosion if you compile lazily, > waiting until the first application for a certain combination. This > was an experiment. Apparently, it works well enough in practise. The > *big* possibility is that since each compiled method in the method > cache has typed arguments, there is the opportunity for *very* > interesting optimizations, such as elimination of a lot of the type > dispatch (e.g. that in accessors and in other calls to generics). Interesting! Well, off to hack, or something. Thanks for the note. Andy -- http://wingolog.org/