Re: So, what the heck is a continuation anyway?

[Michael Vanier <address@hidden>]

> Date: Mon, 10 Dec 2001 23:59:38 -0500 (Eastern Standard Time)
> From: "S. Alexander Jacobson" <alex@shop.com>
> Cc: Bruce Lewis <brlewis@alum.mit.edu>, <ll1-discuss@ai.mit.edu>
> X-X-Sender: alex@mail.vo.com
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: owner-ll1-discuss@ai.mit.edu
> Precedence: bulk
> 
> On Mon, 10 Dec 2001, Dan Sugalski wrote:
> > Still, the tack I'm taking with the engine is to make as much as reasonable
> > part of the core. Yeah it violates the "small, simple, and elegant"
> > principle, but that's OK with me. :) The more functionality, and the more
> > advanced functionality, that the core engine provides, the less low-level
> > annoying stuff people need to do. That leaves more time to do interesting
> > things.
> 
> So why not just translate/compile python/perl to scheme?
> It seems like Scheme already has all the features you want.
> Then you just work with the scheme people to optimize it to execute
> python/perl.
> 
> I know this was sort-of asked before, but I'm not sure I understood the
> answer.
> 
> -Alex-
> 
> 

I'm guessing that translation to scheme and then interpreting scheme would
not be as efficient as translating to bytecode and interpreting the
bytecode, especially since many (most?) scheme implementations have their
own bytecode interpreters (so you've got an extra step right there).
Translation can also be pretty slow and fraught with its own pitfalls
(witness the problems the guile folks have had with just the approach you
describe).

Also, having a register machine as the bytecode interpreter gives a lot of
opportunities for optimizations which might not be there in a scheme
implementation.  Finally, full scheme is probably overkill for this task;
it was designed as an end-user language, not a target language (just like
C).  The Parrot VM, if it supports all these scheme features, would in fact
be a great platform to build a scheme on top of.

Mike