[plt-scheme] [ANN] Heist: a Scheme interpreter in Ruby

Dear James, speaking of learning: consider implementing Ruby
as a macro in PLT Scheme next. I bet that you'd learn a lot.

And while I am writing an email to you: Olin Shivers is on
the record saying that "you can write a Scheme interpreter in
an afternoon, but you may spend a life-time maintaining it."
What he really meant is that writing an interpreter for
Scheme is really a trivial task. If you know EOPL or PLAI
you design the interpreter and derive the abstract machine
for your favorite language during the day time and you will
write the run-time library during night time (assuming the
language is GCed). But then people will start using your
silly little interpreter, and before you know it, you have
a bug database and you want to please those people and ...
life's up. Got to go.

So do contemplate implementing X in Y where *nobody* has
done the ground work before.

-- Matthias





On Feb 24, 2009, at 8:15 PM, hendrik at topoi.pooq.com wrote:

> On Wed, Feb 25, 2009 at 12:20:53AM +0000, James Coglan wrote:
>> Hi all,
>>
>> Just a quick announcement that I've just released the first alpha  
>> version of
>> Heist, a Scheme interpreter in Ruby. It's currently fairly
>> arithmetic-focused, but it also has runtime support for some of  
>> the more
>> tricky stuff like tail recursion, macros and first-class  
>> continuations. More
>> info on my blog, and on Github:
>>
>> http://blog.jcoglan.com/2009/02/25/announcing-heist-a-new-scheme- 
>> implementation-written-in-ruby/
>> http://github.com/jcoglan/heist/
>>
>> Feedback very much appreciated. I know people are forking it  
>> already, and
>> while this is very gratifying I should point out I'm currently not  
>> accepting
>> patches as I'm writing this mostly for my own education.  
>> Implementation
>> advice and literature will be very gratefully received, however.
>
> You might actually learn a lot from receiving, understanding, and
> installing patches.  Or from merging other peoples' branches (I'm not
> sure what terminology is conventional with git).