Re: structs, records, SMOBs etc.

[mike@olan.com (Michael N. Livshin)]

Mikael Djurfeldt <mdj@nada.kth.se> writes:
> Since Guile is foremost an embedded language intended for extension of
> an application, it is important to provide good support for
> manipulation of application data.
> 
> Therefore I'd like if the new record type could be "mapped" over an
> application struct and if it would enable Scheme level access to
> binary data.
> 
> >From the C level it could look something like this:
> 
>   scm_make_record_type (char *name,
>                         scm_record_field_spec_t **specs,
> 		        SCM (*gc_hook) (SCM obj))

You also want a `print' and `equalp'.

>   typedef struct {
>     char *name;
>     scm_record_field_type_t type;
>     scm_record_field_access_t access;
>     int len;
>   } scm_record_field_spec_t;
> 
>   typedef enum {
>     SCM_FT_CHAR,
>     SCM_FT_SHORT,
>     SCM_FT_INT,
>     SCM_FT_SCM_NO_GC,
>     SCM_FT_SCM_GC,
>   } scm_record_field_type_t;
> 
>   typedef enum {
>     SCM_FA_OPAQUE,
>     SCM_FA_READONLY,
>     SCM_FA_READWRITE
>   } scm_record_field_access_t;

Looks OK.

> All field types which aren't opaque would be accessible from Scheme,
> i.e., it is possible to call `record-accessor' for them.
> 
> The `len' field could be used to specify an OPAQUE block of binary
> data to "skip", or could be used to specify an array of fields of
> similar type.

Yes.  SCM_FT_CHAR means single-byte chars, right?

> Maybe it should also be possible to put a pointer to a record field
> spec array inside another record field spec array to support the
> situation when a struct contains another struct, or when it contains a
> pointer to another struct.

I don't like it.  You can have records that contain other records, in
ordinary SCM fields, so no need for this complexity.

> If the gc_hook is NULL, a standard function will be used (which looks
> after SCM_FT_SCM_GC fields).  If the user wants special treatment he
> can supply his own gc routine.
> 
> The record field spec would be "compiled" by make_record_type into a
> format which is maximally efficient for the garbage collector.  This
> compiled spec would be stored in the "type object".

Currently I'm using a dedicated SMOB type for record types.  The thing
contained in the SMOB looks like this (tentative):

typedef struct {
    SCM name;
    scm_field_spec_t * fields;
    scm_sizet numfields;
    SCM (*mark) SCM_P((SCM));
    scm_sizet (*free) SCM_P((SCM));
    SCM print;
    SCM equalp;
} scm_record_type_t;

> If we represent the new records the same way as the current structs,
> we can store a pointer to the type object in the CAR (where the
> current "vtable" is stored), and a pointer to the data structure in
> the CDR.

I think it's better for records in my initial implementation to be
represented by SMOBs.  I'm more comfortable with SMOBs, and structs
won't have to be removed yet :).  Then, when folks will be happy with
the interface, structs will die and so records will be represented as
you describe.  Is that OK?

> /mdj

regards,
mike.