From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: tomas@fabula.de Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Doc organization (Re: Around again, and docs lead role) Date: Fri, 9 May 2003 10:15:56 +0200 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <20030509081556.GB5437@www> References: <3E92E1B4002B0632@pop3.tiscalinet.es> <3EAFE4EC000D9733@pop1.tiscalinet.es> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1052464613 18733 80.91.224.249 (9 May 2003 07:16:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 9 May 2003 07:16:53 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri May 09 09:16:52 2003 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 19E27f-0004rr-00 for ; Fri, 09 May 2003 09:16:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19E27b-0002Qd-00 for guile-user@m.gmane.org; Fri, 09 May 2003 03:16:47 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19E275-0002Ke-00 for guile-user@gnu.org; Fri, 09 May 2003 03:16:15 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19E273-0002Ha-00 for guile-user@gnu.org; Fri, 09 May 2003 03:16:14 -0400 Original-Received: from [217.22.192.104] (helo=www.elogos.de) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19E270-0002Fw-00; Fri, 09 May 2003 03:16:11 -0400 Original-Received: by www.elogos.de (Postfix, from userid 5002) id A96171457F; Fri, 9 May 2003 10:15:56 +0200 (CEST) Original-To: Neil Jerram Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Original-cc: guile-devel@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: General Guile related discussions List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:1925 gmane.lisp.guile.devel:2302 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2302 On Wed, May 07, 2003 at 10:06:57PM +0100, Neil Jerram wrote: [...] > Interesting. It was my idea to document the whole Guile API in the > current unified way, covering both C and Scheme together, but I have > been wondering about whether that was a good decision. In many cases > it seems to result in adding a subsection saying "And there are also > these related C functions and macros ...", which feels unsatisfactory. There have been good answers to this elsewhere. As long as there is a (not necessarily exhaustive) good correspondence between C functions and Guile (with a way to know when to expect what), I'm fine. [...] > Specifically, I think we should (**) promote doing as much programming > as possible in Scheme, and restrict documentation of the C API to the > parts needed for interfacing Scheme to C code. (To give a concrete > example from another thread, I see no need for people to write C code > that uses scm_internal_catch.) [...] > That's what I'm thinking now, anyway. I think (**) may be quite > controversial, so that at least needs a lot more discussion first. To take the other side of the controverse ;-) There have been comments on this elsewhere already, mentioning mod-guile. I won't repeat those. What seemed missing to me (or I was asleep while reading, actually this happens .-) Embedding Guile in applications like Apache or PostgreSQL[1] poses some constraints: Guile won't be the only embedded language. Those applications bring along services for error handling, which you better use (e.g. aborting a transaction/erroring out in an HTTP request/response cycle), for consistency. So it might be most natural to catch errors at the C level. If that is not desirable from a Guile POV, then there should be at least a ``recommended canonical way'' (say: a C function calling a Guile wrapper calling...). And this might be provided as convenience library. But then, it could be provided in the first place :-) I'd even go a step further: for the embedded scripting language to play really nicely in those two cases, it'd be desirable to be able to adapt the garbage collector to the transaction-based memory model: much of the memory used just lives for a transaction, and that's why they allocate memory in `pools', which just disappear after the transaction is done. But this might be just wishful thinking... -------- [1] I'm talking of embedding Guile in the PostgreSQL server, not of a libpq interface _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user