Re: thanks

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

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> (gratuitious CC to the guile-list)
> 
> jimb@red-bean.com writes:
> > 
> > > Just  a quick note to say thanks for the good work you've been doing
> > > on GUILE:
> > > 
> > >    Thanks!
> > 
> > Thanks, Han-Wen.  I do wish I'd been able to help you more with
> > Guile-ifying LilyPond, but I don't think I had much insight into the
> > issues.
> 
> Integrating GUILE has learned me much about how interpreters and
> Scheme works.  I had to skip to the .c sources directly to find out
> what I was looking for many times. I don't have a problem with that,
> since the sources are very clean, but others may have.
> 
> (climbing soapbox)
> 
> So I think that there is definitely a need for more documentation.
> 
> Also, I think that the gh_ interface is not very useful, if you build
> an application that has more complex functionality than an interpreter
> with a REP loop.
> 
> Browsing lily sources reveals calls to scm_assoc, scm_assoc_set_x,
> scm_reverse ,scm_mkstrpor, scm_ftell, scm_eval_x, scm_read,
> scm_fill_input, scm_puts, scm_unprotect_object, scm_protect_object,
> and lots more. I don't think the gh_ interface is rich enough for my
> purposes, and frankly, I still don't know what it is for exactly.

It really should provide a lot of that (if you consider gh to be a
common substrate suitable for any scheme interpreter, then maybe stuff
like protect_object shouldn't be part of gh, but just about everything
else should be). Just looking at your list:

scm_ass*, scm_reverse: all should be in there. Maybe gh_assoc with an
optional arg for whether it should use eq?, eqv? or equal? (oops,
common lisp leaking out ;).

scm_mkstrport: iffy... isn't there a srfi about string ports? If it's
final, there should be something similar to that interface.

scm_eval_x: yes, something like this should be in there (for some
reason, gh_* will only deal with strings).

scm_fill_input: this really shouldn't be exposed to the outside
world; use normal io functions ;) (though these are probably sparse in
gh :( 

scm_puts: yes (for some reason, the strings are only dealt with in
gh_eval... ;).

scm_protect...: this is really specific to guile. It could be in
there, and if anyone's providing this interface for another scheme,
they can just make it a noop if it doesn't make any sense. I discussed
(quite briefly) the possibility of a srfi for common gc control
options sometime last year, but there are a lot of issues with this,
due to the fact that pretty much every implementation will have a
different garbage collector (though it could have the caveat that
nothing is guaranteed to do anything if it steps on the gc's toes or
doesn't make any sense given the implementation of the gc). 

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.

-- 
Greg