GRIN as intermediate representation for Lazy Functional Languages

By: on November 1, 2005

Shae Erisson points out Urban Boquist’s GRIN thesis. It’s very interesting: the choice of the GRIN intermediate language allows a number of good optimisations. A control-flow analysis is done to enable inlining of evals. The information the analysis computes is similar to the kind of information you get from dynamic profiling in a Self-like system – which is why I’m finding it interesting. I’m building a lazy functional object-oriented language, and I want to use Self-like dynamic optimisation techniques to recover efficiency. It’s nice to see it being done!

FacebookTwitterGoogle+

3 Comments

  1. Shae Erisson says:

    Is the source for your language available?
    Also, in case it wasn’t obvious, John Meacham is building JHC on top of a GRIN backend.
    What’s the relation between polyinline caching and GRIN?

  2. tonyg says:

    The relationship between PICs and GRIN was more that PICs compute a similar kind of control-flow-analysis graph to the one being computed over GRIN code. The reason GRIN is interesting is more that it’s a lazy functional language, and I wasn’t 100% convinced that I would get good results from partial-evaluation in a lazy setting.

  3. tonyg says:

    I’ve just made my darcs repo available at http://www.eighty-twenty.org/hgwebdir.cgi/smalltalk-tng/file/default/. I’ll write a posting for http://eighty-twenty.org/ that explains the layout of the code. My current experiments, “r3″, are little more than a parser at the moment, and I think even that might be a bit broken. Still – have a look if you like :-)

Post a comment

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>