From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Backtrace and enhanced catch Date: Sun, 22 Jan 2006 15:47:08 +0200 Message-ID: <8764oc4boj.fsf@zagadka.de> References: <200511301616.22258.bkorb@gnu.org> <87wthpkyan.fsf@ossau.uklinux.net> <43B69F41.6030509@xs4all.nl> <87hd8pb8o7.fsf@ossau.uklinux.net> <87lkxy3abo.fsf@ossau.uklinux.net> <877j9i31gc.fsf@ossau.uklinux.net> <87acebhf1o.fsf@ossau.uklinux.net> <87oe2foubc.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1137946910 23636 80.91.229.2 (22 Jan 2006 16:21:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2006 16:21:50 +0000 (UTC) Cc: hanwen@xs4all.nl, guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Jan 22 17:21:49 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F0hyI-0001uv-C5 for guile-devel@m.gmane.org; Sun, 22 Jan 2006 17:21:42 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0htf-0006EI-OS for guile-devel@m.gmane.org; Sun, 22 Jan 2006 11:16:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F0hKS-0008Dz-27 for guile-devel@gnu.org; Sun, 22 Jan 2006 10:40:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F0h9a-0004Ao-Kq for guile-devel@gnu.org; Sun, 22 Jan 2006 10:31:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F0fbR-0008Dq-OZ for guile-devel@gnu.org; Sun, 22 Jan 2006 08:50:01 -0500 Original-Received: from [213.243.153.36] (helo=smtp3.pp.htv.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1F0fg0-0000E1-J4 for guile-devel@gnu.org; Sun, 22 Jan 2006 08:54:41 -0500 Original-Received: from zagadka.ping.de (cs181072157.pp.htv.fi [82.181.72.157]) by smtp3.pp.htv.fi (Postfix) with SMTP id 41F0527AC82 for ; Sun, 22 Jan 2006 15:47:14 +0200 (EET) Original-Received: (qmail 26612 invoked by uid 1000); 22 Jan 2006 15:47:09 +0200 Original-To: Neil Jerram In-Reply-To: <87oe2foubc.fsf@ossau.uklinux.net> (Neil Jerram's message of "Sat, 14 Jan 2006 12:41:43 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:5606 Archived-At: Neil Jerram writes: > The main part of this patch is appended below, and I would appreciate > any comments that anyone may have Looks very good to me. Please go ahead. Thanks! One (minor?) point I have is the term "lazy". I am not sure if it is the right term to use. It has meaning for people who already know lazy-catch, but I'd say it is not really descriptive of what it does. Something like "pre-unwind" handler might give a better hint of how it differs from the 'post-unwind' handler. Hmm, what I'm trying to say here that "lazy" is not some standard, established terminology, and if we come up with something better, we should feel free to change terminology. > One point is that I have removed the "SCM_API" from the declaration of > scm_i_with_continuation_barrier. My understanding is that > scm_i_with_continuation_barrier (like scm_i_* functions in general) is > a libguile-internal function and so does not need to be exported from > the libguile DLL in a Windows build (which is what SCM_API is for). Yeah. I have to say that I don't really understand the meaning of SCM_API. I mostly treat it is as a purely technical thing: you need to use it when you want code outside this DLL to call the function. I don't treat it as a way to document what is in the Guile API and what isn't. For example, a macro or inline function that is in the Guile API might expand into a call to a scm_i_ function. That function than needs to be flagged with SCM_API although it is not part of the API. I see no point in preventing people from calling internal functions as long as they know that they are internal. That's why I put SCM_API on all functions with global scope. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel