From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: ffi docs Date: Fri, 16 Apr 2010 23:34:50 +0100 Message-ID: <87wrw7t4ad.fsf@ossau.uklinux.net> References: <87ljco1gyc.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271457307 19788 80.91.229.12 (16 Apr 2010 22:35:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 16 Apr 2010 22:35:07 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Apr 17 00:35:06 2010 connect(): No such file or directory Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O2u7u-0006pG-2n for guile-devel@m.gmane.org; Sat, 17 Apr 2010 00:35:06 +0200 Original-Received: from localhost ([127.0.0.1]:51706 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2u7t-0006q2-Jt for guile-devel@m.gmane.org; Fri, 16 Apr 2010 18:35:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2u7m-0006px-1a for guile-devel@gnu.org; Fri, 16 Apr 2010 18:34:58 -0400 Original-Received: from [140.186.70.92] (port=53035 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2u7k-0006pp-GI for guile-devel@gnu.org; Fri, 16 Apr 2010 18:34:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2u7h-0001ng-UW for guile-devel@gnu.org; Fri, 16 Apr 2010 18:34:56 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:35331) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2u7h-0001nU-IX for guile-devel@gnu.org; Fri, 16 Apr 2010 18:34:53 -0400 Original-Received: from arudy (host86-186-3-37.range86-186.btcentralplus.com [86.186.3.37]) by mail3.uklinux.net (Postfix) with ESMTP id E9D2E1F6856; Fri, 16 Apr 2010 23:34:51 +0100 (BST) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 185D03801F; Fri, 16 Apr 2010 23:34:51 +0100 (BST) In-Reply-To: (Andy Wingo's message of "Fri, 16 Apr 2010 11:33:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 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:10243 Archived-At: Andy Wingo writes: > Hi, > > Thanks for the feedback! Thanks for the quick responses. As far as most of them are concerned, I'll read the section on foreign functions first before offering more thoughts, as you suggest. Also I agree that it will make sense for me to handle these doc changes. On a couple of specific points.... > On Fri 16 Apr 2010 00:36, Neil Jerram writes: > >>> But yet we as programmers live in both worlds, and Guile itself is >>> half implemented in C. So it is that Guile's living half pays respect >>> to its dead counterpart, via a spectrum of interfaces to C ranging from >>> dynamic loading of Scheme primitives to dynamic binding of stock C >>> library prodedures. >> >> c -----------^ > > What does this mean? I'm sorry! It was supposed to indicate a typo, and that there should be a "c" at the place the caret points - i.e. "procedures" rather than "prodedures". Anyway, I'll handle this. >>> We titled this section "foreign libraries" because although the name >>> "foreign" doesn't leak into the API, the world of C really is foreign >>> to Scheme - and that estrangement extends to components of foreign >>> libraries as well, as we see in future sections. >> >> I'm not sure what the message is here. > > Probably me being to cutesy, I would imagine. I didn't think that! > The facility is typically > called a "foreign function interface", but that name doesn't appear in > e.g. "dynamic-link", so I was trying to explain. Ah yes, I see now. In that case I think it's just the last clause that doesn't quite work for me. I would say that the _immediately_ following text is about "components of foreign libraries", so why say "as we see in future sections"? Maybe: "... really is foreign to Scheme. Foreign function and data pointers, obtained via `dynamic-func' and `dynamic-pointer', or as return values from a foreign function call, are inherently untyped, and depend on the Scheme programmer using them in a way that is consistent with the library's documented interface. Any other usage is unsafe and can easily cause the containing Scheme program to crash, and the Guile low-level FFI cannot protect against this. (This is quite different from computations on Scheme values; Scheme values are typed, and so operations on them can check in advance that the value types are as expected.)" >> Code below implies that library can be omitted, and that this - >> i.e. '(dynamic-link)' - means to return an object representing libguile >> itself. Should that be mentioned in the following doc? >> >>> Find the shared library denoted by LIBRARY (a string) and link it >>> into the running Guile application. When everything works out, >>> return a Scheme object suitable for representing the linked object >>> file. Otherwise an error is thrown. How object files are >>> searched is system dependent. >>> >>> Normally, LIBRARY is just the name of some shared library file >>> that will be searched for in the places where shared libraries >>> usually reside, such as in `/usr/lib' and `/usr/local/lib'. >>> >>> When LIBRARY is omitted, a "global symbol handle" is returned. >>> This handle provides access to the symbols available to the >>> program at run-time, including those exported by the program >>> itself and the shared libraries already loaded. > > I think it is mentioned, no? Is there a way that it can be more clear? I'm sorry. I can't believe I missed that. I looked for it so carefully! >> - isn't it actually much more to do with the ELF binary format, rather >> than with C? If libguile could read and parse C, it would be able to >> infer the type of any variable that the Scheme layer might request. >> The problem is precisely that what we are linking with is *not* C >> anymore... It's just untyped pointers. > > I guess you're right, this is confusing. C doesn't really exist at > runtime, and this API is all about accessing runtime values. On further reflection, I think I'm not completely right. Functions assume that they will be called according to well known C calling conventions. So I guess there are vestiges of C. Out of interest, do other languages that compile to library format use different calling conventions, and if so can dlopen/dlsym and FFIs work with them? More tomorrow... Regards, Neil