chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multiple environments


From: Diogo Behrens
Subject: Re: Multiple environments
Date: Sun, 16 Jun 2024 15:57:55 +0200

Hi Felix,

Thanks for the reply.

On 16. Jun 2024, at 11:27, felix.winkelmann@bevuta.com wrote:

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.

Indeed, this has the issue that the module passed as second argument is not mutable.

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.

Actually, no. I was planning not to compile the actors code. The idea is that the simulator takes the a “model” as input besides the number of actors. The model is the code executed by the actors. I guess that this boils down to using eval, right?

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?

For the globals that are *shared* among actors, I’m already using an interface. That makes the accesses to shared data fully explicit (it’s just a hash-table in the background). But I wanted to allow the user to write the actors’ “models“ as plain scheme. At the end of the day, however, this is not a tremendous problem. I was just curious to see if it would be possible to implement.

For now,  I will follow your suggestion and move the accesses to global state (whether shared or not) behind a get-put interface. I think that later, using macros, I can hide/simplify the input of the user.

Thanks for the suggestions.

Best,
-Diogo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]