Re: gh_enter reconsidered

[Tel <telford@eng.uts.edu.au>]

> > Whenever I mention the issue to the authors of other embedded
> > interpreters, they say that they could not imagine the need to (1)
> > burden their users with such an arcane approach as SCM's, and (2) use
> > such an implementation-dependent feature as a top of stack.
> > 
> 
> Hmm, so how do they protect objects on the stack against GC? Do you
> have to protect them explicitly? I know perl uses reference-counting
> GC (or did last I heard), so I imagine they at least do that.

The perl man pages that I have access to say that objects are reference
counted that's not really an option for scheme lists.

> I think having objects on the stack automatically protected is very
> much a big enough win to merit doing some system-dependent hackery.

Any gh_eval_blah() function that is called from C can easily detect
where it's OWN stack begins so it can guarantee garbage collection
for all local variables on the stack under itself with no trickery at all
and be totally portable. This includes any and all C functions that
are called in the process of the eval, the stack can only grow in one
direction so we are totally safe until the original gh_eval_blah() actually
returns...

However, the only value that is going to cause a problem is the
actual SCM value returned by the eval -- all this effort is just to
protect that one single value.

Currently, gh_enter() graciously protects the user from accidently losing
it's return value by never returning. If instead it converted the
return value away from a SCM then the whole problem would just go away.

Many applications principly want a scripting language to invoke side
effects anyhow and don't give a bean about what the return value is
but still, you can't be too careful, these users may get a SCM value
that they can't handle...

All we need is a void gh_enter() that is allowed to return, a bar that
prevents any eval outside of the sphere of gh_enter() and then the
user can make use of scripting for side effects if they want to, while
popping in and out of the SCM sphere whenever they need to.
We already have restrictions on storing SCM values in global variables and
since global variables would be the only way to pass values out when
gh_enter() returns void, no additional restrictions have been incurred.

Yes I know people might call scm_cons() before they call gh_enter(),
they might do it now, they might do a lot of things, big deal.

The value of scheme symbols would always still be garbage collected since
these are in a global location the is always known to guile -- only the
stack is at issue here.

Interrupt vectors that have been defined in scheme would have to be
reset as gh_enter() returns but if a program really wants guile to take
over interrupt handling then that program probably won't be bothered
by having gh_enter() take over the main(). If it really is bothered then
it will work but suffer a performance hit as interrupt vectors get set and
reset all the time, again, big deal, at least the system is usable.

Anyhow, I've said this before and the current situation doesn't bother
my particular application so I guess I'm past caring at this point.

	- Tel