This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: How often are continuations created?


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > So, it looks like you need to allocate bindings that might get mutated
> > in external frames, on the heap.
> > 
> > Is that right?
> 
> Right.  And I think I have done this already:

I see.  But why are you putting a and b into external frames?  Because
they are mutable?  Or because there is a call/cc lurking?

I think you want to be able to optimize things like

    (do ((i 0 (1+ i)))
        ((= i N))
      (vector-set! v i (magic-computation i)))

into code that doesn't use an external frame for `i' and likewise does
not create a fresh frame for every iteration.  When you use only a
single frame (which is legitimate because the binding of i can not be
captured by a closure), you need to modify it.

But magic-computation might use call/cc in a way that would invalidate
the assumption that we do not need a new frame for every value of `i'.
Hmm.  Can bindings be made optimistically intern, and be externalized
when they are captured by call/cc?
 
> BTW, my VM has a %jump instruction, and the intermediate code of the
> compiler has #:label and #:goto keywords.  I think writing a
> compiler could be easier than writing a translator when we have a
> VM.

I think it would be easier to provide support for the features of your
VM on the Scheme level and then translate to Scheme.  For example, we
could have something like the `tagbody' of Common Lisp and your
compiler could generate efficient code for it.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]