From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Han-Wen Nienhuys Newsgroups: gmane.lisp.guile.devel Subject: Re: guile/workbook/extension/dynamic-root.text Date: Thu, 30 May 2002 14:28:04 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <15606.6868.682999.22226@meddo.cs.uu.nl> References: <200205300728.AAA00154@morrowfield.home> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1022761789 16423 127.0.0.1 (30 May 2002 12:29:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 30 May 2002 12:29:49 +0000 (UTC) Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17DP3s-0004Gm-00 for ; Thu, 30 May 2002 14:29:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17DP4D-0003qR-00; Thu, 30 May 2002 08:30:09 -0400 Original-Received: from sunset.cs.uu.nl ([131.211.80.32] helo=mail.cs.uu.nl) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17DP2K-0003fv-00 for ; Thu, 30 May 2002 08:28:12 -0400 Original-Received: from meddo.cs.uu.nl.cs.uu.nl (meddo.cs.uu.nl [131.211.80.91]) by mail.cs.uu.nl (Postfix) with ESMTP id 096C1455E for ; Thu, 30 May 2002 14:28:04 +0200 (MET DST) Original-To: guile-devel@gnu.org In-Reply-To: <200205300728.AAA00154@morrowfield.home> X-Mailer: VM 7.03 under Emacs 21.2.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:675 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:675 lord@regexps.com writes: > In a stackless implementation, since you can easily have precise GC, > you can easily have _incremental gc_. > There is a smooth migration path: if you start by making `eval' and > `apply' stackless, you can still provide "backwards compatible" > interfaces for built-ins that expect a stack-full, conservative-GC > system. You can gradually fix such built-ins in the core, and perhaps > eventually deprecate the compatability interface. Yes, it also destroys GUILE's biggest asset, and the very purpose of why GUILE came to be: easy integration with external packages (written in C) SCM foo (SCM x) { x = scm_acons (gh_symbol2scm("bar"), gh_int2scm(1), x); /* non conservative GC at this point will munge the head of x. */ x = scm_acons (gh_symbol2scm("baz"), gh_int2scm(2), x); return l; } I think this has been discussed before, and I still think that it is a Bad Idea. ObGuile: What's keeping the 1.6 release? Lurking around, I only see lots of discussion on tiny details that could just as well be fixed in a 1.6.1 `bugfix' release. I would really like to require GUILE 1.6 for Lilypond 1.6 (which is to be released in a few months) -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen/ _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel