In other words, each 'case' in the argument to the with-program-cases macro has a slight differentbody, which is given by a list of different choices which is prefixed by the #? reader macro.Preferably, i would also want to be able to define the macro so i could have something like this #?([for y = x] [for y = 1]) where the brackets would indicate that for y=x and for y=1 would be pasted into the appropriate place without surrounding parentheses. But that's for another time!

I figured i would implement this by making the reader macro #? append the appropriate data to two global variables, *cases* and *case-vars*. The macro with-program-cases would then use this data to expand into an intermediate state given by the following (using the first example above):

The problem occurs when there are multiple with-program-codes expanded at the same time.First, all the reader macros are expanded. When the with-program-cases is macroexpanded,it now sees all the data pertaining to all the cases within each with-program-cases body. In other words, it hasno clue which data belongs to itself. So, what i need, i think, is either a totally different way to do this whole thing ,or some way to communicate between the reader macros and the with-program-cases macro that surrounds them.Thix!

Side effecting read macros are a bad idea. There is no guarantee that they will be executed once when expanding, and in general run into weird issues like the one you have here. What I would do if trying something like this is to make the read macro expand to some unexported symbol, and then walk the source tree in with-program-cases rebuilding the tree.

I think that in this case you can get away without a full code walker even, as this is just a source tree transformation, rather than syntax tree. This would make the #?([for y = x] [for y = 1]) mostly trivial as well, as you could just make it expand into a different marker symbol.