This is the mail archive of the guile@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] |
>>>>> "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