GRIN as intermediate representation for Lazy Functional Languages
This page is a mirrored copy of an article originally posted on the (now sadly defunct) LShift blog; see the archive index here.
Tue, 1 November 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!
Comments
On 2 November, 2005 at 8:09 pm, wrote:
On 3 November, 2005 at 3:34 pm, wrote:
I’ve just made my darcs repo available at http://eighty-twenty.org/~tonyg/Darcs/smalltalk-tng/. 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 :-)
On 3 November, 2005 at 3:36 pm, 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.
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?