Re: Multiple environments

[Anton Idukov]

Hi! 

Theoretically, the way is

  (load "module.so" local-eval)  

where is

(define local-eval (let ((e (scheme-report-environment 5 #t))) (lambda (sexp) (eval sexp e)))))

In reality the chicken version  of (scheme-report-environment version [mutable]) 

does not take the second parameter (mutable #t), 

how it say  'scheme module' docs https://wiki.call-cc.org/man/5/Module%20scheme#eval 

Error: bad argument count - received 2 but expected 1: #<procedure (scheme#scheme-report-environment n)>

So I think not just global vars but dynamic parameters and form (parametrize...) the only way https://wiki.call-cc.org/man/5/Module%20(chicken%20base)#parameters 

or I'm wrong.

вс, 16 июн. 2024 г. в 12:27, <felix.winkelmann@bevuta.com>:

> I’m looking for an elegant way how to manage multiple environments (global bindings) to build a concurrency simulator. The input of my simulator is the number of actors/coroutines/etc. I would like to have fully separate environments for these coroutines, so they can mutate variables with same name and won’t affect each other. The communication between each actor is not done via shared variables.
>
> [...]
>
> I know I could use variables in the lambda scope, but I would prefer to avoid restricting the actors implementation.
>
> I have a prototype in Racket, where I use make-base-namespace to create namespaces for each actor. I can then call eval with the lambda as first argument and the mutable namespace as second.
>
> Would somebody in the mailing list have a suggestion how to handle this in an elegant way in CHICKEN?

Hi!

You can use modules in combination with "eval" to isolate global environments.
First you create a module at runtime using via "(eval '(module ...))" and then
evaluate an _expression_ in the context of the module by using "module-environment",
passing this env as a second argument to eval. This has several restrictions,
though, so it is not equivalent to the way your Racket implementation works.

Also you probably want to compile your code instead of evaluation code at
runtime. Would it be possible to use a different syntax for global variable
accesses (both read and write, so something like "get" and "put" operations)?
That would make the implementation much easier and also has the benefit of
making global accesses more obvious to the one reading the code and it also
helps to make the code more portable to other Scheme implementations.

Is the set of globals fixed or can an actor extend this set? Do you want to
compile your code (I assume you do)? Do you want these globals to be fully
equivalent to normal global bindings?


felix