Re: [Chicken-users] the effect of set! on the top-level namespace

[Shawn Rutledge]

On 10/15/07, Stephen C. Gilardi <address@hidden> wrote:
> The current thread in this mailing list "On parameterize and fluid-
> let" is all about that.

I don't think it's quite the same.  The context is for callbacks - say
there is a top-level event handler (like a keyboard event handler).
You launch an app inside a Chicken-based windowing system, and a new
window is created.  As long as that window has focus you want its
keyboard handler to be used instead of the top-level one.  But when it
loses focus or is destroyed you want to pop back to the old keyboard
handler.  (And for that matter, the new window might even want to
sometimes fall back to the old handler when it doesn't wish to handle
a particular event.)  Fluid-let would not allow the window's keyboard
handler to replace the existing one outside the scope of that window's
code; but (for example) the code which polls the keyboard is running
in the top-level scope.  So it has to be a top-level stack.

Solutions I can think of: the usual one in other languages is to plan
for this and use a level of indirection - there is a focused-widget
variable and the main event handler delegates to that.

Or I could define some syntax, call it define* or something, which
would use an assq-list mapping variable names to stacks of previous
bindings (or use that new symbol property list that Felix just added).
 define* pushes and undefine* pops.  There is no overhead unless you
use it... you can use define originally and then define* later to
override it.  set! changes only the current binding and doesn't affect
any "stacked" previous bindings.  (And * might not be the right
adornment... have to think about whether this usage is consistent with
the others.  Maybe should instead call it define! or push-define or
something.)