Re: Thinking again about parameters in the VM
Michael Campbell <mike <at> ghettogroup.com>
2012-01-14 07:49:39 GMT
Actually, I most often run into this problem when I'm working at the
REPL and reloading modules containing parameters referenced by code
called in other threads. I reload the module defining the parameter,
and then my other (existing) threads blow up due to what are
effectively new parameter objects, from their point of view.
The obvious work-around is to always use some kind of a macro with
semantics like CL's 'defvar' (vs 'defparameter') or Clojure's
'defonce' for defining parameter objects, but then of course I have to
remember to actually use it instead of 'define'. This approach mostly
works, except in the (fairly rare) cases where I decide to change a
parameter's default value, which need to be handled manually, one way
or another.
It sounds like your proposed global parameter table would do away with
these issues completely though.
On Fri, Jan 13, 2012 at 11:08:03PM -0500, Kirill Zorin wrote:
> One way would be to create a global table that holds all parameters
> ever initialized (per module, I suppose, since the module system is
> global as well) paired with their initial values. Then the parameter
> getter procedure can be modified to check, on ref error, if the "same"
> parameter exists in the table, and if so, to initialize a new
> parameter of the same name in its own local storage using the initial
> value stored in the table.
>
> This would only fire for parameter ref errors, and we're assuming here
> that most programs are at least well formed enough to not rely on or
> exhibit parameter ref errors frequently.
>
(Continue reading)
RSS Feed