Re: RFC: Foreign objects facility

[Doug Evans <xdje42@gmail.com>]

On Tue, Apr 29, 2014 at 11:25 AM, Andy Wingo <wingo@pobox.com> wrote:
> Hi!
>
> Thanks for the feedback, it's really useful.
>
> On Tue 29 Apr 2014 17:56, Doug Evans <xdje42@gmail.com> 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 <foreign-slot>, 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.