[plt-scheme] Re: expansion continuations and barriers

From: Robby Findler (robby at cs.uchicago.edu)
Date: Tue Jul 24 17:52:23 EDT 2007

On 7/24/07, David Van Horn <dvanhorn at cs.brandeis.edu> 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.

There are multiple ways to ensure one's invariants in the presence of
call/cc and there is no question that inserting prompts or
continuation barriers is easier than making the expander safe for
arbitrary returns to expanders.

So, you've got yourself a feature request, not a bug report, unless
you can show that some use of continuations causes the expander to
fail in some unforseen way.


Posted on the users mailing list.