Re: GC questions.

[Michael Livshin <mlivshin at bigfoot dot com>]

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

> mlivshin@bigfoot.com writes:
>
> >  this scares me.  if we improve the smob interface to work with any
> > collector we could invent, we'll improve it to complete unusability.
> 
> I don't understand; in what way is proposal unusable?  If I understand
> correctly, the current approach is that every assignment in a
> smob-routine be done by a scm_assign macro. I don't consider that very
> ergonomic.

me neither.  that's why I want to keep the smob API *as it is*, so
that those who don't generate their Guile glue with SWIG or something
won't have to tear their hair out.  I'm even going to implement some
pretty scary kludges to make it possible with GenGC.

note: this basically means that smobs will be scanned by every GC.  I
think it's OK in the circumstances.

> > a better angle might be to standartize on some glue code generator
> > and
> > simply not bother with the naked smob interface.
> 
> Oh no! A code generator, how would it work? Does it parse C code? If
> yes, how will you make sure that it also understands arcane C++
> declarations?

see what I mean? ;)

> > When your hammer is C++, everything begins to look like a thumb.
> 
> amen.

I wish you could meet my .sigmonster socially, it's quite nice and
friendly when you get to know it ;).

-- 
All ITS machines now have hardware for a new machine instruction --
SPO
Skip if Power Off.
Please update your programs.