From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: RFC: Foreign objects facility Date: Tue, 29 Apr 2014 20:25:08 +0200 Message-ID: <87ha5cuh6j.fsf@pobox.com> References: <87bnvm52u6.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1398795937 23631 80.91.229.3 (29 Apr 2014 18:25:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Apr 2014 18:25:37 +0000 (UTC) Cc: guile-devel To: Doug Evans Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 29 20:25:32 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 1WfCih-0007gU-OF for guile-devel@m.gmane.org; Tue, 29 Apr 2014 20:25:31 +0200 Original-Received: from localhost ([::1]:51749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCih-0001t4-Av for guile-devel@m.gmane.org; Tue, 29 Apr 2014 14:25:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCiX-0001sn-4A for guile-devel@gnu.org; Tue, 29 Apr 2014 14:25:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfCiS-0001TM-BA for guile-devel@gnu.org; Tue, 29 Apr 2014 14:25:21 -0400 Original-Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:63745 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfCiS-0001TH-6I for guile-devel@gnu.org; Tue, 29 Apr 2014 14:25:16 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B2F521052F; Tue, 29 Apr 2014 14:25:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=N64paWN/MtrsSuJZ3zmWkipwUCE=; b=RcjSl+ NVeZ8wMdlkF2WTsA+asF5bWHoOyaYEruFka4TPLDlbkAwrVqky+jtUOgM71NciWD rskMki8+RtVsOSVoqW4eY5aYZ3/JldSKZ9YOOS+RN7/9XHUXAvBiCUq84kWSNS4P 5vwJdC+M3WE00ZQFo1a5d4/f1uLKV0yIdRGkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=DIY22S54eLARYfZ4tRRlHcsjhNT4EmJM ieZluzh7uLYDNBic+nk5HTL2Kufzs0ELWHqRWbNWQC+98BiW6Eo1oHpCpEDThpXS H8o7WzNRuzX2Zb7mrlx7jOtyMBAD33ynxUvzCLw2eGlE/zwNsjo1KlnDFGOz9pf3 PjMgiOG1P3A= Original-Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id AA3A71052E; Tue, 29 Apr 2014 14:25:15 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 11AE71052D; Tue, 29 Apr 2014 14:25:11 -0400 (EDT) In-Reply-To: (Doug Evans's message of "Tue, 29 Apr 2014 08:56:39 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Pobox-Relay-ID: 9A279D52-CFCB-11E3-9340-6F330E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 208.72.237.25 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:17117 Archived-At: 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. > 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. 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. > 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). > 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? 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." WDYT? Andy p.s. Will reply to your other mail, but see the updated master docs here: http://www.gnu.org/software/guile/docs/master/guile.html/Programming-in-C.html#Programming-in-C http://www.gnu.org/software/guile/docs/master/guile.html/API-Reference.html#API-Reference -- http://wingolog.org/