Home » forums » LtU Forum

machine-ported reference algorithms

The following sentence, at http://danny.sadinoff.com/hebcal/, got me thinking.

Hebcal has been successfully ported to Perl, C, and Javascript, but I'm currently only maintaining the C implementation.

How can we avoid such situations? In my opinion they are all too common.

Before I go further, let me assure you that I am not trying to open up a discussion lamenting the Tower of Babel problem or naively proposing that language X (possibly invented by me) is the one everyone should use everywhere.

But what I would like to get some input from LtU members about is, how can a reference implementation of an algorithm be machine-ported to a variety of languages? My premise is that this would be desirable for the Hebrew calendar algorithms and many other algorithms like it. Such an algorithm would have the following properties.

  • Valuable to call natively.
  • Tricky to port.
  • Expected to have maintenance, i.e. expected to have need to re-port (merge).
  • Not performance sensitive.
  • Though valuable to call natively, not important to be implemented idiomatically.

    By "valuable to have natively" I mean valuable to have inside a language instead of outside it, e.g. cases where the following are true.

  • Not good to have as a C library (e.g. host language is not C, C++, or a language in which an FFI to C is available).
  • Not good to have as a library in one of the bytecode VM ecosystems (e.g. host language is not a JVM or .NET language).
  • Not good to have as a separate process that can be talked to via some IPC mechanism like IO streams, files, or command-line arguments.
  • Not good to have as a web service. I guess a web service could be thought of as a distributed IPC mechanism but I thought it was worth calling out on its own.

    So, if an algorithm has these properties, it would be nice to have a reference implementation in some language that could be what I call "machine-ported," which could mean machine-translated or interpreted, i.e.

  • Be machine-translated to a variety of other languages.
  • Be interpreted inside a variety of other languages.

    Has anyone done this, e.g.

  • Here's my reference algorithm in (possibly-novel) language X and here are its machine-translations into languages A, B, and C.
  • Here's my reference algorithm in (possibly-novel) language X and here are interpreters for X written in languages A, B, and C.

    Note that in the interpreted strategy, the interpreter is provided along with the code instead of being expected to be present in the host language. So this is different from the a proposal of a universal extension language (e.g. Lua embedded everywhere). Such proposals are interesting, but suffer somewhat from the same problems as proposals of a universal host language (e.g. Java everywhere).

    Thoughts?

    • By bdenckla at 2011-10-13 18:30 | LtU Forum | previous forum topic | next forum topic | other blogs | 3918 reads

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.

    Not sure if anyone has...

    but I have a student working on a very similar idea. I'll report back when there is tangible progress. The first target algorithm is actually Quicksort. I was thinking of an interpreter and Gaussian Elimination next, but hebcal is an interesting candidate too.

    By Jacques Carette at Fri, 2011-10-14 02:44 | login or register to post comments