[plt-scheme] Re: expansion continuations and barriers

On Tue, 2007-07-24 at 17:35 -0400, David Van Horn wrote:
> Ryan Culpepper wrote:
> > Control effects often interact badly with mutation. For example, a
> > popular almost-implementation of 'map' is to iterate through the list,
> > accumulate the result list in reverse order, and 'reverse!' it at the
> > end. Unfortunately, if one of the calls to the argument procedure
> > captures a continuation, and if the program later invokes that
> > continuation, then parts of the result list will be 'reverse!'d twice,
> > and you'll get a garbled result.
> > 
> > I expect that allowing full continuations during expansion would garble
> > the mutable data structures used to implement recursive scopes. You
> > could write a macro that defined a name but also defined a companion
> > macro that you could invoke to "take back" the definition.
> 
> By this line of reasoning, I would think you're arguing that the 
> expander is broken (like the almost-implementation of map), not the code 
> that uses let/cc.

No. There are certain parts of the system that execute code but require
the code to be "well-behaved" with respect to control. You can use
continuations all you want within your own code (including locally
within the context of a single macro transformer, a single MrEd callback
handler, etc), but your use of continuations cannot interfere with your
interactions with the system. If you search Help Desk for "continuation
barrier" it will show you a list of such places.

> I am trying to implement a library for writing macros in monadic style, 
> similar in spirit to SRFI 53.  The implementation technique there is to 
> translate everything into CPS "under the hood".  Is this the only 
> feasible technique for this kind of thing?

You might try 'local-expand'. Put the core forms in the stop list and
interpret them yourself. Then you'll have control over the continuations
(pardon).

Ryan