From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: Threads and asyncs Date: Mon, 2 Sep 2002 16:24:35 -0700 (PDT) Sender: guile-devel-admin@gnu.org Message-ID: <200209022324.QAA08246@morrowfield.regexps.com> References: <87it1oglmq.fsf@zagadka.ping.de> <200209022124.OAA07625@morrowfield.regexps.com> <87k7m43si7.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031008293 5304 127.0.0.1 (2 Sep 2002 23:11:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 23:11:33 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17m0Ly-0001NO-00 for ; Tue, 03 Sep 2002 01:11:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17m0NV-0008HR-00; Mon, 02 Sep 2002 19:13:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17m0ND-0008F2-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 19:12:47 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17m0NB-0008Dj-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 19:12:46 -0400 Original-Received: from 1cust167.tnt13.sfo8.da.uu.net ([63.10.241.167] helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17m0N9-0008Dc-00; Mon, 02 Sep 2002 19:12:45 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id QAA08246; Mon, 2 Sep 2002 16:24:35 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: rlb@defaultvalue.org In-Reply-To: <87k7m43si7.fsf@raven.i.defaultvalue.org> (message from Rob Browning on Mon, 02 Sep 2002 18:02:08 -0500) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 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:1230 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1230 From: Rob Browning > If I understand correctly, one of the reasons guile used the "one (C) > stack with copying" approach was so that call/cc could work properly > with a stack that included intermixed C and scheme function calls > without too much extra magic. If that's a correct assesment, then how > do you deal with that problem in a stackless approach? Well, blush.... I think I initially overvalued that feature. I (nowadays) don't think it should be central to _any_ implementation. Instead, i'd make an implementation that is good as just a pure scheme implementation, then add in that seductive integration with that C stack via a foreign-function interface. I think a good pure scheme is not at all likely to use the C stack that way, especially for procedures of central importance like `apply' and `eval'. Most primitives, especially the core ones, would not rely on using the C stack in the manner of SCM. But since Guile is an extension language, one should _be able to_ write primitives that way (i.e. C-stack friendly), perhaps with a modest performance trade-off, when necessary. That would let people add Guile to programs with minimal disruption. In fact, the C-stack-friendly API could be made largely implementation independent. If Guile never budges on the stack issue, I would still be inclined to see it as an implementation optimized for cases when the C stack is used heavily. > It was also my impression that the call/cc issue, along with an > aversion to having to explicitly deal with GC on the C side (which as > you've pointed out before might be dealt with via preprocessing, > etc.), were the two main things that would make switching to a > stackless approach somewhat controversial or difficult. Are those the > only two big issues, or are there others? You've caught me talking from memory. We'd need to sit down with a wiki or whiteboard and map it out together. I won't pretend to be able to list all the issues off the top of my head. I won't pretend to have finished my own personal map of the various design spaces :-) Do you have a good library of Scheme implementation papers? Maybe there should be a collaborative bibliography to bring together a bunch of the good ideas floating around out there. -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel