On Wednesday 14 January 2004 10:22, Kjetil Svalastog Matheussen wrote:
Not exactly, all code is run in the same interpreter. But the (define) thing is to let each instance run in its own namespace.
Is what you refer to as a "namespace", the same as what Common Lisp would refer to as a "closure"? In common lisp, such a function definition would create a "closure", which is I think a persistent "environment", and "environment" being a set of symbol bindings more or less.
Say you have the following script called setnum.scm:
(define number 0) (pd-inlet 0 'setnum (lambda (n) (set! number n))
If you have two [k_guile setnum.scm] objects in a pd patch and the scripts are loaded into the global environment, "number" will be written from both objects, because they both use the same "number" variable.
Ok, I'll try that - should be an interesting experiment.
But still, the problem is, if I want to load Common Music for example, where would I do that? Certainly I don't think it would work to re-load it upon every PD object instantiation, because who knows what when it first gets loaded. And certianly, the global symbols in Common Music should remane truly global. I think the only safe thing would be to load it once only, before any PD objects that use scheme get loaded. Or else have some global flag somewhere that causes Common Music to load only on the first object that needs to use it. But again, my experience is with Common Lisp, and not Scheme, so it's entirely possible that the difference between these languages has my very confused at the moment.
Incidently, I'm really doubting about how using seperate interpreters for each object could work for someone who wants to use Common Music in scheme within PD.
But hopefully other people who are more experienced in Scheme as a opposed to Common Lisp, will chime in here. It could well be that I'm missing some level of understanding, or am simply of the minority opinion.
Scheme is built around environments, which is a namespace. For each new lambda/define a new environment is made. (Or something like that, at least)
The second reason is that by including global.scm and local.scm directly into the k_guile.pd-linux binary instead of loading the files somehow, there is no problem finding those files when running the k_guile external. local.scm and global.scm aren't supposed to be changed very often anyway.
I personally don't agree with this argument. No matter what, in order to make use of your external, those scheme files need to be available. The only distinction is whether you need them at the time you build the external, or whether they need to be there at the time you load the external into PD. Either way, they need to be there.
Users don't have (or at least shouldn't have) any need for local.scm or global.scm by runtime, and the files are therefore unnecesarry when running k_guile. Letting the files be loaded at runtime only introduce extra unnecesarry complexity for the user.