From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Doug Evans Newsgroups: gmane.lisp.guile.devel Subject: Re: RFC: Foreign objects facility Date: Tue, 29 Apr 2014 08:56:39 -0700 Message-ID: References: <87bnvm52u6.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1398787011 31033 80.91.229.3 (29 Apr 2014 15:56:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2014 15:56:51 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 29 17:56:47 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WfAOl-00080k-67 for guile-devel@m.gmane.org; Tue, 29 Apr 2014 17:56:47 +0200 Original-Received: from localhost ([::1]:50818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfAOk-0004FH-Tz for guile-devel@m.gmane.org; Tue, 29 Apr 2014 11:56:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfAOg-0004ET-Bu for guile-devel@gnu.org; Tue, 29 Apr 2014 11:56:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfAOf-00064i-05 for guile-devel@gnu.org; Tue, 29 Apr 2014 11:56:42 -0400 Original-Received: from mail-yh0-x236.google.com ([2607:f8b0:4002:c01::236]:54659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfAOe-00064N-RB for guile-devel@gnu.org; Tue, 29 Apr 2014 11:56:40 -0400 Original-Received: by mail-yh0-f54.google.com with SMTP id b6so396172yha.41 for ; Tue, 29 Apr 2014 08:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CAUq/9YDE4j5whC1IEoYsrFNASILzmXLt5QhFIeyQ+g=; b=scS9YJzeTNWfI88By45APL2ovxXROczLCjMmY49PKZ/EUA9jK2VO4YTL3+k6jx23Dw UsIVyxFg4uqJPAzIQQZaQSD+o9RyIiGCF+uwMszANSpO+hV2DJ0jo1ClKlBQopXUG7HZ F2VLcm7OSfWmjH1vCmAiopKKQJ0h9b/kbJKZKUpx3R+Ir4U8WrQfMLaBk6VO6JsXuhIb aPCIpWDt6MgDRs7IHkK8NcAKBMnyGpkSLtfWREIS7aNbkP03asWgs5AtxNcjuo29msWN 1tR/JM/kKsW/KS2mQR8jOYx7kIGexlhPDYncp9GQvjzyy+Iq7wwAwoLaiU6qQCs3Z6bd +mcw== X-Received: by 10.236.216.73 with SMTP id f69mr47759349yhp.37.1398786999365; Tue, 29 Apr 2014 08:56:39 -0700 (PDT) Original-Received: by 10.170.214.130 with HTTP; Tue, 29 Apr 2014 08:56:39 -0700 (PDT) In-Reply-To: <87bnvm52u6.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c01::236 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17114 Archived-At: On Sun, Apr 27, 2014 at 6:17 AM, Andy Wingo wrote: > Hi, > > SMOBs have a few problems. > > 1) They are limited in number to 255. > > 2) It's difficult to refer to a SMOB type from Scheme. You can use > class-of once you have an object, but the class-of isn't exactly > the same as the SMOB tc16, and getting the type beforehand is > gnarly. (See http://article.gmane.org/gmane.comp.gdb.patches/96857 > for an example). > > 3) You can't create SMOB types from Scheme. This goes against our > general trend of making Scheme more powerful. > > 4) You can't create SMOB objects from Scheme. > > 5) Similarly, you can't access SMOB fields from Scheme. > > 6) You can't subclass SMOB types. (Some people would like this > ability.) > > 7) There is legacy code out there that uses e.g. SCM_SETCDR to set > smob fields. (This is terrible, but it exists: > https://github.com/search?q=SCM_SETCDR+smob&ref=cmdform&type=Code > for an example.) > > 8) The single/double SMOB thing is outdated and bogus. Objects should > be able to have any number of fields. > > 9) We document mark functions in the manual, even recommending them, > but they are really difficult to get right (see > https://lists.gnu.org/archive/html/guile-user/2011-11/msg00069.html), > and almost always a bad design -- the BDW GC can do a better job > without them. > > And yet, if we consider the generic problem of wrapping C objects in > Scheme objects, it's clear that we have more solutions now than we used > to -- raw # values, define-wrapped-pointer-type, etc. But > there's nothing that's accessible to C like SMOBs are, so people that > use the libguile interface to wrap C types and values are out of luck. > > I propose to provide a new interface that will eventually make SMOBs > obsolete. This new interface is based on structs with raw fields -- the > 'u' fields. (See > http://www.gnu.org/software/guile/docs/master/guile.html/Vtables.html#Vtables > for description of 'u' fields. Note that the documentation is wrong -- > these fields are indeed traced by the GC.) > > Here is the proposed C API: > > SCM scm_make_foreign_object_type (SCM name, SCM slot_names, > scm_t_struct_finalize finalizer); > > void scm_assert_foreign_object_type (SCM type, SCM val); > > SCM scm_make_foreign_object_1 (SCM type, scm_t_bits val0); > SCM scm_make_foreign_object_2 (SCM type, scm_t_bits val0, > scm_t_bits val1); > SCM scm_make_foreign_object_3 (SCM type, scm_t_bits val0, > scm_t_bits val1, scm_t_bits val2); > SCM scm_make_foreign_object_n (SCM type, size_t n, scm_t_bits vals[]); > > scm_t_bits scm_foreign_object_ref (SCM obj, size_t n); > void scm_foreign_object_set_x (SCM obj, size_t n, scm_t_bits val); > > The finalizer may be NULL. The scm_make_foreign_object* functions are > just scm_make_struct without the no_tail arguments, and interpreting the > values as raw untagged values, not unpacked SCM values. Same thing with > scm_foreign_object_ref/set_x. The struct interface, contrary to what the documentation says, takes a stdarg list beginning with the number of fields (and not terminated with SCM_UNDEFINED), instead of _1, _2, _3. fwiw, I would use that over the _n version. I'd probably even use it instead of _1,_2,_3, but I know some people like the comfortableness of having the compiler verify the number of args is correct. I'm not sure if gcc could be extended to handle verifying stdarg functions where one parameter specifies the number of stdarg parms (assuming it doesn't support that already). fwiw, structs already provide most of what is needed. I have a few gdb objects using them, and it doesn't seem too bad. I think you should fix/extend the struct interface instead of inventing something new: given that structs already have "uninterpreted" it is most of the way there already. It's already intended to solve the problem you're trying to solve. Its API just needs a way to set/ref "uninterpreted" values directly. Plus making foreign objects completely usable from Scheme kinda removes any usefulness of having "foreign" in the name. With a bit of tweaking of the struct interface you're done. So why invent something new?