[plt-scheme] unexpected behavior of top level continiuations

On Sun, 12 Sep 2004 10:22:41 -0700, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sat, 11 Sep 2004 14:33:10 -0500, Corey Sweeney wrote:
> > In fact R5RS does not require a working scheme
> > implemenation to be compliant. So I'm forced to wonder, why were
> > continuations implemented this way in Drscheme
> 
> The semantics of `load' or `read-eval-print-loop' in DrScheme is
> `read', then `eval', then `print', then `read', etc.
>
> In your first example, the "this was not in the continiuation" part was
> still in the port at the time that the continuation was captured (i.e.,
> not yet `read'). Capturing the continuation does not capture the state
> of the port, so that's why the "this was not in the continiuation" part
> wasn't captured by the continuation.

ok, this makes sence now.  
 
> > and why is the top
> > level left out of the R5RS?  is it some deep technical reason, or more
> > of a apathy issue?
> 
> It's difficult to make the top-level work consistently for different
> uses of a program, such as interactive evaluation and batch
> compilation. This is why we switched to `module', and it's why
> DrScheme's various tools don't really try to deal with non-`module'
> programs.

Hmm.  I'll have to think on this for a while before I have a oppinion
on this.  I wonder if any work has been done on checkpointing the data
in the ports during a call/cc.

Now up till a few hours ago, my idea of a "module system" was using a
closure (as evidenced by my code :).  I'm reading how "advanced"
module systems can help modularize macros via "Composable and
Compilable Macros", but am still a bit fuzzy on things.  from a
programming perspective, does the module count as a "top level"?  And
do the continuations work without the mentioned "port buffer issues"?

Feel free to direct me to further module system explanation documemtation.

> 
> Matthew