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

Chris, the better option might be to figure out an FFI for calling his Pascal code directly, link in the Open MPI via the existing FFI, and create the cluster-based program you want. In a sense, you'd use Racket as a scripting language for gluing together code. BUT, doing so leaves open the option of moving code across the FFI barriers on a piecemeal basis and that is the real benefit: 

 everything is incremental. 

I am sure people on this list will be willing to help as you move forward. 

-- Matthias






On Oct 5, 2010, at 8:27 PM, Neil Van Dyke wrote:

> 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.
> 
> -- 
> http://www.neilvandyke.org/
> _________________________________________________
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/users