Re: gh_enter reconsidered

[Eric Moore <moore@chem.cmu.edu>]

>>>>> "Tel" == Tel  <telford@eng.uts.edu.au> writes:

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

It seems to me that this isn't really any better than the current
mechanism, since either a) you need a single entry point into scheme
(i.e. all the guile code is called through a single piece of
functionality) or b) you're going to be passing functions to gh_enter
left and right, and gh_enter will have to be able to be called within
a gh_enter context (confusing, IMO).  

It's also a bit of overhead to make sure you're "inside" a gh_enter
context all the time.

Your mechanism works if there's only one function that calls scheme
code, but I think most apps will have lots of entry points into scheme
code, and I think that untangling the whole mess will be a lot of
work, and lead either a lot of duplicated code (gh_enter called in
every function that calls scheme) or obscure bugs (someone calls a
function that uses scheme, but doesn't have it's own gh_enter, because
when it was first written it was only called from functions that were
called within a gh_enter).

 -Eric