From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Threads and asyncs Date: Mon, 02 Sep 2002 18:02:08 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87k7m43si7.fsf@raven.i.defaultvalue.org> References: <87it1oglmq.fsf@zagadka.ping.de> <200209022124.OAA07625@morrowfield.regexps.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031007726 4008 127.0.0.1 (2 Sep 2002 23:02:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 23:02:06 +0000 (UTC) Cc: mvo@zagadka.ping.de, 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 17m0Cq-00012W-00 for ; Tue, 03 Sep 2002 01:02:04 +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 17m0EI-00069V-00; Mon, 02 Sep 2002 19:03:34 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17m0Cy-0005vL-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 19:02:12 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17m0Cw-0005v9-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 19:02:12 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17m0Cw-0005v5-00; Mon, 02 Sep 2002 19:02:10 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id C2AE698F1; Mon, 2 Sep 2002 18:02:09 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id E9DD1E9E; Mon, 2 Sep 2002 18:02:08 -0500 (CDT) Original-To: Tom Lord In-Reply-To: <200209022124.OAA07625@morrowfield.regexps.com> (Tom Lord's message of "Mon, 2 Sep 2002 14:24:50 -0700 (PDT)") Original-Lines: 32 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) 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:1229 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1229 Tom Lord writes: > There are other alternatives, such as radical changes to the execution > model, so that C stacks aren't used by Scheme at all. In my personal > Scheme design, this is the route I've (more or less) decided on. When > worked out, and made to work cleanly with primitives written in > "classic C style" (i.e., freely calling eval or apply), I think it > winds up converging on more-or-less the same solution as making > call/cc work by transformation to CPS. 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? 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? (fairly interested in the topic ATM) Thanks -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel