s c h e m a t i c s : c o o k b o o k

/ Cookbook.ProvidingSetBangableIds

This Web

TOC (with recipes)

Other Webs



Schematics Home
Sourceforge Page
Original Cookbook

Scheme Links

Scheme FAQ
Scheme Cross Reference
Scheme48 SCM
MIT Scheme scsh
JScheme Kawa
Chicken Guile
Bigloo Tiny
Gambit LispMe

Lambda the Ultimate

How to provide identifiers that can be mutated with set! directly


In MzScheme, you can set! identifiers that you defined within your own module, but usually attempting to set! identifiers that you imported from other modules will fail.

This is a good thing in general, since it allows module writers to reason locally about whether invariants for its identifiers are maintained. This leads to easier correctness arguments, and can also be a boon for improving execution speed for code (e.g., a compiler can detect if an identifier is never mutated, and generate better code).

However, sometimes you do want to be able to allow clients of your module to mutate state that you maintain. One way to do this is to provide "setter" procedures, which the client calls to mutate state. This is useful in some cases, but also can be a burden on the client (e.g. if they already have built up a large body of code that uses set! directly on identifiers in the top-level environment, and do not want to modify it to use a new protocol just because an identifier moved from the top-level to a module).


The following module defines a provide-settable special form. Any identifier provided with provide-settable is then able to be used with set! in a client module.

500 Can't connect to (connect: Connection refused)

The solution relies on the support of syntax-id-rules, which broadens macro invocations to identifier references and set! expressions (rather than just straightforward combinations). PLT Scheme added support for syntax-id-rules circa version 205.8.

Now I can use this as follows:

500 Can't connect to (connect: Connection refused)

If we have only used provide to export x, then MzScheme would complain the code in module B, because it attempts to mutate x. By using provide-settable, B can mutate x and is unaware of the machinery under the hood (such as the call to the setter procedure).

(If someone knows how to write this macro without using syntax-case, I'd like to hear about it.)


Matthias Felleisen pointed out to me that a similar trick is documented (along with a introduction to syntax-rules and syntax-id-rules) in Dr. Dobb's, April 2004, "Building Little Languages with Macros."

Eli Barzilay pointed out to me that when threads come into the picture, you may want to use a parameter to represent the state, rather than a standard global varable.

Felix believes that this is a matter of adapting the first macro to develop something like the following macro definition (where id-parameter is an appropriately constructed parameter value). 500 Can't connect to (connect: Connection refused)

Note the distinction between (id-parameter) and (id-parameter EXP); the first acts as our "getter", while the second acts as our "setter."

Comments about this recipe


-- PnkFelix - 21 Jun 2005

TopicType: Recipe
ParentTopic: IdiomRecipes
TopicOrder: 999

Copyright © 2004 by the contributing authors. All material on the Schematics Cookbook web site is the property of the contributing authors.
The copyright for certain compilations of material taken from this website is held by the SchematicsEditorsGroup - see ContributorAgreement & LGPL.
Other than such compilations, this material can be redistributed and/or modified under the terms of the GNU Lesser General Public License (LGPL), version 2.1, as published by the Free Software Foundation.
Ideas, requests, problems regarding Schematics Cookbook? Send feedback.
/ You are Main.guest