Re: The GH interface. (was: Patch for gh.h)

[Rob Browning]

"Dale P. Smith" <address@hidden> writes:

> Well, it (supposedly) provides for version independence.  When you use
> the scm_ interface, you use a lot of macros that know about the details
> of internal structures.  The parallel gh_ routines are function calls.
> 
> It should be possible to not have to recompile or even relink your app
> if you use the gh_ interface, even if the layout of SCM or other data
> structures change.  Look at the difference between gh_car and SCM_CAR
> for example.

Ahh.  Good point.

Well, if that's considered important and something that the gh_
interface is intended to guarantee, then we should definitely make
sure that goal is documented clearly (if it's not already), so we'll
know we need to add duplicate gh_ functional definitions of many of
the SCM_ operations.

We'll still have to answer questions like this, though:

If there's already a scm_ function that's totally appropriate for
public use, say scm_less_p, do we need to #define gh_less_p
scm_less_p, or do we just document that the "public" C level interface
to guile is the gh_interface plus *some* of the scm_ interface?

Further, if we do think #define gh_less_p scm_less_p is the way to go,
but we also think a design goal for the gh_interface is C orientation,
do we really need to prefer

  #define gh_less_p(x) (scm_less_p((x)) != SCM_BOOL_F)

?

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930