GRIN as intermediate representation for Lazy Functional Languages

(This page is a mirrored copy of an article originally posted on the LShift blog; see the archive index here.)

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!


On 2 November, 2005 at 8:09 pm, Shae Erisson wrote:

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?

On 3 November, 2005 at 3:34 pm, tonyg wrote:

I’ve just made my darcs repo available at I’ll write a posting for 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 :-)

On 3 November, 2005 at 3:36 pm, tonyg wrote:

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.