[racket] racket, scheme, and message-passing clusters?

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Tue Oct 5 20:27:10 EDT 2010

chris lanz wrote at 10/04/2010 11:14 AM:
> I have to rewrite all my original code in SOMETHING (it's in PASCAL 
> because that's what I'm virtuosic in and that's what I've been using 
> for 25 years) and I was preparing to rewrite in C and use MPI, but 
> I've decided it's better to switch all at once.

If this is a huge amount of Pascal code, and you see the rewrite as a 
major undertaking, here's an idea...

One of the features of the Racket toolset is the support for mixing 
languages.  So, if you had tons of legacy code, you could make a "#lang 
lanz-pascal" that, when Racket sees it at the top of a Pascal file at 
compile time, the Pascal gets translated to a "#lang racket" module.  
Possibly, this gives you the option of a smoother and faster migration 
path, if it makes all your code runnable quickly.  Then you can rewrite 
individual Pascal modules in more optimal handwritten Racket, or begin 
building upon the Pascal modules with all-new behavior in Racket modules.

 From my fuzzy recollection of Pascal, it seems that transliteration of 
Pascal to Racket is easy for much of the language.  One tricky thing 
that comes to mind: you might have to come up with policy for 
translating "var" and pass-by-value parameters of different types, 
depending on how your code base uses them.  (Or extend your Pascal 
language to add new keywords to give hints to the translator on how some 
uses of tricky things should be handled.)  Possibly similar policy 
decisions to be made with translating pointer vs. value, although I 
suspect that decisions is most likely to be to just treat everything as 
a reference.  If your code uses features of arrays and structs that 
don't translate trivially to Racket vectors and structs (e.g., strange 
array index ranges), then you can either define new ADT types for 
Pascal-like arrays and Pascal-like records, or you can have the 
translator do more work when it translates uses of these.

Approaches like this don't always make sense, but that Racket supports 
this as an option for when it does make sense is one of the several 
reasons that Racket is my favorite language platform.

Regarding Gambit, if you stick mostly to R5RS Scheme features, I think 
that moving from Racket to Gambit is not difficult if you ever need to 
do that.  I originally was very careful to be portable, since I wanted 
to be sure I could use Gambit, SISC, or a translator to C when I had to, 
but, for nine(!) years so far, Racket has done everything I've needed.


Posted on the users mailing list.