Re: gh_ interface [was Re: thanks]

[Greg Harvey <Greg dot Harvey at thezone dot net>]

"Greg J. Badros" <gjb@cs.washington.edu> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> <snip>
> 
> > I think a very good idea right now would be for everybody who's
> > writing non-trivial c programs with guile to provide a list of things
> > that they really need that aren't provided by gh (scwm already has
> > something like this, but that may be out of date... I'm sure that scwm
> > has also implemented a lot of good abstractions for some of the
> > missing stuff, so that should probably be the base for extending gh
> > into something really useful). gh (excellent initials, those ;) should
> > be a collection of useful abstractions that allow you to do what you
> > want, without exposing you to exactly how it's done inside guile.
> 
> Our list is reasonably up-to-date and I just re-posted it.

Yeah, it showed up just after I pressed send... I wasn't sure if you'd
given it up as a lost cause; on one particularly itcy point, the
tagged cons thing is something that really needs a solution that
distances it a bit from a `normal' cons cell (it's been all kinds of
fun for the gengc changes too). I think setc[ar]r should only be used
for setting the car to an actual object; something like settag and
setdata (setlength already exists, but it doesn't make a lot of sense
if you're not setting the length of something... I think setdata does
exist in some form, though setchars is often used, which is again
really non-intuitive). The smob changes improve this somewhat, but
there needs to be something used consistantly throughout guile for
normal objects as well.

> Scwm tries to provide abstractions where they are missing, but often
> doesn't for the low-level scm_ stuff since I've always just been waiting 
> for the gh_ interface to improve (perhaps by renaming to gb_*? :-) :-) ).

No, I don't think that would work very well >;'). (then again, it is
gbh :). 

-- 
Greg