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