[PD] Re: [PD-announce] k_guile v0.0.1

[Larry Troxler]

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.