This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: thanks


Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> Greg Harvey <Greg.Harvey@thezone.net> writes:
> 
> > scm_protect...: this is really specific to guile.
> 
> Actually GC protection is rather generic concept, and pretty
> common. 

It is mostly harmless in any case, so it probably should be in there.
I was thinking more of some of the things that I've added for the
gengc (see http://home.thezone.net/~gharvey/guile/gengc-info.txt for
the current list of bits); hrm... actually, all of those things can be
implemented in any scheme (ie, just ignore if you don't want that
information, the assignment stuff has a very easy interpretation if
it's not important to you).

I think I might be rambling here. Here's the point that I'm trying to
get to (and disagreeing with myself :): it doesn't hurt to have these
things, since an implementation of gh for a scheme where they don't
make sense can easily ignore them. This is true for a lot of areas of
guile that've that've been discussed, though I'm not quite sure that
you could do this for smobs, since the format of the functions you
create are really dependant on how the being used represents
them... it's probably inevitable that things which are really
divergent between scheme implementations really won't be able to find
a least common interface. I think that smobs are one case where it's
probably just as well to stick with the scm interface, since they are
very specific to guile (and, as a bonus, the new smob interface is
much more sensible :).

> Also, it is implementation independant if you provide gh_cons
> - then gc_protect is just
> 
> global_protect_list = gh_cons (object, gh_protect_list);
> 
> (while this would be rather inefficient for unprotects - you might
> want to provide gh interface for hash tables and use them instead).

Actually, this is the way protects are done now :( (the performance
does suck... and in some places it's used when it's not needed, so
that makes things worse). There was a patch to use hashes for the
system protects a while back, but I don't really have time to look for
it right now (a few assignments due). It should probably avoid consing
totally, though.

> > 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.
> 
> I think this is an issue to discuss.
> 
> Many parts of scm_ interface are just straigtforward C bindings of
> RnRS. For example, scm_cons, scm_assq_* etc is just Scheme directly
> translated into C. This seems like a reasonably
> implementation-independant part of the interface. So... Is there a
> point in writing gh wrappers around these? Would it do to just use
> #define to alias scm_cons to gh_cons instead? Or to split scm_
> interface into guile specific (e.g. smob functions) and general
> (RnRS library functions) and document it as such?

I think you want the gh interface to be somewhat more robust than the
guile interface; on the guile side of things, it's sometimes not a bad
idea to foresake rigourous type-checking in favour of speed (i.e, for
some functions you can assume the caller already did checking); the gh
interface should never do this.

As an alternative, there could always be a rnrs_ set of functions (but
is that clouding things a bit too much?). 

-- 
Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]