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: Fri, 2 May 2014 22:45:52 -0700 Message-ID: References: <87bnvm52u6.fsf@pobox.com> <87ha5cuh6j.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 1399095965 2823 80.91.229.3 (3 May 2014 05:46:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 May 2014 05:46:05 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 03 07:45:59 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 1WgSlp-0005mK-Og for guile-devel@m.gmane.org; Sat, 03 May 2014 07:45:57 +0200 Original-Received: from localhost ([::1]:47597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgSlp-0003rH-EW for guile-devel@m.gmane.org; Sat, 03 May 2014 01:45:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgSlm-0003rC-TN for guile-devel@gnu.org; Sat, 03 May 2014 01:45:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgSll-0001qs-O9 for guile-devel@gnu.org; Sat, 03 May 2014 01:45:54 -0400 Original-Received: from mail-yh0-x22f.google.com ([2607:f8b0:4002:c01::22f]:42629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgSll-0001qG-Jh for guile-devel@gnu.org; Sat, 03 May 2014 01:45:53 -0400 Original-Received: by mail-yh0-f47.google.com with SMTP id a41so2569645yho.20 for ; Fri, 02 May 2014 22:45:53 -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=n/1Xl37P8VcSBzBI3Q6dRn5kdOPxsTVsm6EkPlk0Hcc=; b=AQ8y7143AeuXoB0MJmNpZ//jRr9zafkUQ0eTgcOkGEEI9crWOognPowXvIc8vtuwU+ CYhEZ1YL/00E5ZYMGEE8BjbgVsHKoBvZzwctNhpdatkcD68imrympzqMYMpZoFzLAUCf Gx5IjfwJXMsMYJMujQQgH/2M8oyP+T8YYTnCpp3kE7ZCK1f4aYritORU0oDwiy/c+VpB OgEAjZknioQNADZHWElCiPUuB316biMWnTZRVfuoD1+1nqJD4WQhPNY9PFW8jF3n+xO7 WBylsPqVIdfvEzm5axEHindLcJZSLcFYH633eCldyjDoc5d9oJAJWGw/ToMgsmQQIj26 PbTg== X-Received: by 10.236.157.167 with SMTP id o27mr29324454yhk.127.1399095953046; Fri, 02 May 2014 22:45:53 -0700 (PDT) Original-Received: by 10.170.214.130 with HTTP; Fri, 2 May 2014 22:45:52 -0700 (PDT) In-Reply-To: <87ha5cuh6j.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::22f 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:17134 Archived-At: On Tue, Apr 29, 2014 at 11:25 AM, Andy Wingo wrote: > Hi! > > Thanks for the feedback, it's really useful. > > On Tue 29 Apr 2014 17:56, Doug Evans writes: > >> 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 > > This is what the documentation says (in the info node 'Structure > Basics'): > > -- C Function: SCM scm_make_struct (SCM vtable, SCM tail_size, SCM > init_list) > -- C Function: SCM scm_c_make_struct (SCM vtable, SCM tail_size, SCM > init, ...) > -- C Function: SCM scm_c_make_structv (SCM vtable, SCM tail_size, > size_t n_inits, scm_t_bits init[]) > > I believe this to be correct. Almost. git struct.c has: SCM scm_c_make_struct (SCM vtable, size_t n_tail, size_t n_init, scm_t_bits init, ...) >> fwiw, I would use that over the _n version. > > I thought so too and so I used this in my first attempt ;) However > scm_make_struct expects the scm_t_bits to actually be unpacked SCM > values -- which is to say, it expects them to be tagged. A bit wonky. > SCM is a perfectly valid varargs type, as evinced by scm_list_n and > friends. But that's how it is and for ABI reasons we can't really > change that. I'm not suggesting changing the API of course. :-) Plus scm_make_struct is callable from Scheme so it doesn't really support passing "uninterpretered" values (except hackily). > Then we had the points that Mark brought up about portable type-casting, > and that really we should provide separate signed/unsigned integer > interfaces and also pointer interfaces. It gets into a combinatoric > mess on the constructor level, though perhaps for N<=3 it's manageable. > Anyway then you also have to match the types that are passed as > initializers to the field type (unboxed 'u' or tagged 'p') and it's just > a big mess. I thought that the given foreign object API would cover the > majority of cases, like SMOB cases, and that for multi-field types the > ref/set accessors would be sufficient. Technically, one could provide just intptr/uintptr and skip void*, but the latter would be sufficiently convenient I think. re: The combinatoric mess, I'm not suggesting adding that. Plus, if an app wants to have an SCM in their "foreign object" they can't store it in a slot, whereas they can with structs. >> fwiw, structs already provide most of what is needed. >> I have a few gdb objects using them, and it doesn't seem too bad. > > Yes. The API doesn't support this use case so well. It also doesn't > support GOOPS method dispatch, subclassing, or named fields (unless you > start getting into records territory). IIUC, goops already had , which is what the foreign object API uses. So I still don't see what creating a whole new class of data structure provides that can't be provided by extending existing ones. And if there is something, doesn't that mean that the existing ones (goops/structs) are still broken? >> 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. > > Good point. Though, it can hard to square with the existing smob/struct > cases. You could have scm_struct_unsigned_ref -- would it then untag a > 'p' value? I would flag referencing or setting a 'p' field via the "uninterpreted" accessors as errors. > It seems to me that there are some combinatorics that we do > away with by saying that "this is a foreign object. It's also a struct, > and a GOOPS instance, and you can treat it that way, but the API we > expose to C is the most useful way to treat these objects." OTOH, yet another compound data structure with its own API now exists.