Re: To gh_ or not to gh_?

[Rob Browning]

Keith Wright <address@hidden> writes:

> This is either a revelation (to me) or a revolution (in Guile)!

I think it's probably a minor possible revolution, but one based on
elapsed time from which we've hopefully learned something :>

The problem is that the mission statement of the gh_ interface seems
too vaguely defined to be useful, and so that needs to be fixed.  Once
that's done, it should be obvious what should happen.

> My impression was that the 'scm_' interface is an ancient artifact,
> inherited from Aubrey Jaffer's proto-guile, which is to be
> superceded by the new designed-for-guile, yet implementation
> independant 'gh_' interface.  The 'scm_' interface, if not
> deprecated, was soon to be labeled "for hackers of Guile internals
> only", while the 'gh_' interface was to be completed and made
> useable for most purposes.

Well, it is possibly "ancient", but it's by no means an artifact.
It's really the only way to do anything non-trivial from C using
guile.  For example, say you have two SCM objects, and you want to see
if one is less than the other.  If you go look in the gh_ interface,
there's no way to do it (without a lot of gh_apply and
gh_eval_str'ing), but in numbers.h, you will find:

  SCM scm_less_p(SCM x, SCM y);

which seems about as interpreter independent as you're likely to get.

The real question is, what is the gh_ interface for?

Some other interesting questions:

  - Is it an interface that should be stable in the face of
    libguile.so changes?  If so, then a lot of the #define gh_foo
    scm_foo declarations need to be fixed.

  - Is it an interpreter independent interface?  If so, why?  Also, if
    so, what makes scm_less_p and many related functions
    inappropriate.  If we do decide gh_ is critical, do we then need
    a bunch of wrappers like

      int gh_less_p(SCM a, SCM b)
      {
        return scm_less_p(a, b) != SCM_BOOL_F;
      }

    or do we eventually just drop scm_less_p in the source in favor of
    gh_less_p?  Recall that you can't use #defines for the gh_
    interface if it's supposed to be stable across libguile.so
    releases.

etc.

I don't deny that we may need "levels" to the interface, and that even
gh_ itself might be used to denote an important distinction, but we
need to know what that distinction is.  Jim's comment about
high-performance vs. portability is also interesting, and we have to
decide if there's enough to be gained to warrant maintaining two
interfaces, *and* if using a separate prefix is the right way to make
this distinction.

One thing that we've been discussing on guile-devel is, at a minimum,
starting to hide all the scm_ functions that are considered "private"
by default, either with private headers, or more likely with a #define
SCM_INTERNAL or similar.  This would help make it clear which of the
scm_ functions are intended for public consumption.

Hope this helps.

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