GRIN as intermediate representation for Lazy Functional Languages
November 1st, 2005 tonyg
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!
Entry Filed under: Technology
3 Comments Add your own
1. Shae Erisson | November 2nd, 2005 at 8:09 pm
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 | November 3rd, 2005 at 3:34 pm
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 :-)
3. tonyg | November 3rd, 2005 at 3:36 pm
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.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed