CPS and Guile

CPS and Guile

[Noah Lavine]

Hello everyone,

There was some discussion in the "Identities in Peval" thread about
using a CPS-like intermediate representation in Guile.

I think that our goal with our intermediate representation should be
to make things convenient for us - we shouldn't try to match any
particular model unless it helps us, and we should be happy
customizing it for ourselves. From this point of view, I see two
orthogonal issues with Tree-IL.

First, some of the tree-il forms have their own control-flow
properties, which doesn't work well with a uniform representation of
control flow. They also complicate the big match statements in peval.
Why not make dynlet, dynwind, dynref, dynset, prompt, and abort into
primitives? Code that cares can still match them, and code that
doesn't care can ignore them.

Second, the idea of annotating tree-il forms with their continuations.
I think that could actually be done fairly simply, if we remove the
contraint that they have to be useful :-). I'm imagining that at first
continuations would be like source information, in that they are
passed everywhere but the compiler doesn't use them. You could even
keep a separate hash table of continuations if you really wanted to,
but that seems like more effort to me.

I think it would be fine to have a hybrid compiler for bit that did
some analyses using the continuation information and some using the
tree-il structure. That might help with the issue of named primitives,
too - we could still generate code from the tree structure.

What do you think?
Noah

Re: CPS and Guile

[Andy Wingo]

Hi,

On Sat 18 Feb 2012 17:42, Noah Lavine <noah.b.lavine@gmail.com> writes:

> Why not make dynlet, dynwind, dynref, dynset, prompt, and abort into
> primitives? Code that cares can still match them, and code that
> doesn't care can ignore them.

In the case of dynlet, there is an efficiency concern: you already have
the fluids and values -- it's the difference between with-fluids and
with-fluids*.

Dynref and dynset would be fine as primitives.

Prompt has some efficiency concerns as well, related to whether the body
is a closure or not, and whether the handler reifies the continuation or
not.  Abort is tree-il out of symmetry, but also because of the tail
facility (efficiency, again).

> Second, the idea of annotating tree-il forms with their continuations.
> I think that could actually be done fairly simply, if we remove the
> contraint that they have to be useful :-). I'm imagining that at first
> continuations would be like source information, in that they are
> passed everywhere but the compiler doesn't use them. You could even
> keep a separate hash table of continuations if you really wanted to,
> but that seems like more effort to me.

I'd rather introduce letcont forms as Kennedy does in "Compiling with
Continuations, Continued".  Why would we do CPS if the continuations
would not be useful? :)

Andy
-- 
http://wingolog.org/