[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: To gh_ or not to gh_?
From: |
Rob Browning |
Subject: |
Re: To gh_ or not to gh_? |
Date: |
10 May 2001 14:36:04 -0500 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
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
- Re: To gh_ or not to gh_?, (continued)
- Re: To gh_ or not to gh_?, Michael Livshin, 2001/05/04
- Re: To gh_ or not to gh_?, Bobby D. Bryant, 2001/05/04
- Re: To gh_ or not to gh_?, Neil Jerram, 2001/05/05
- Re: To gh_ or not to gh_?, Marius Vollmer, 2001/05/05
- Re: To gh_ or not to gh_?, Keith Wright, 2001/05/07
- Re: To gh_ or not to gh_?, Bill Gribble, 2001/05/07
- Re: To gh_ or not to gh_?,
Rob Browning <=
- Re: To gh_ or not to gh_?, Evan Prodromou, 2001/05/10
- Re: To gh_ or not to gh_?, Neil Jerram, 2001/05/11
- Re: To gh_ or not to gh_?, Keith Wright, 2001/05/11
- Re: To gh_ or not to gh_?, Dirk Herrmann, 2001/05/12
- Re: To gh_ or not to gh_?, Sam Tregar, 2001/05/10
- Re: To gh_ or not to gh_?, Rob Browning, 2001/05/10
- Re: To gh_ or not to gh_?, Sam Tregar, 2001/05/10
- Re: To gh_ or not to gh_?, Thomas Bushnell, BSG, 2001/05/12
- Re: To gh_ or not to gh_?, Jeff Read, 2001/05/10
- Re: To gh_ or not to gh_?, Sam Tregar, 2001/05/11