Syntax conversion for programs written in other languages


Introduction

At the current writing, Yacas is still in its infancy. There are currently systems available that have many more years of development behind them. Maxima for instance has a license that is compatible with the Yacas license (they are both GPL). These systems already implement features and algorithms that Yacas has yet to implement.

The big difference, in this respect, to the other systems is the programming language the code is written in. All these algorithms will have to be re-implemented simply because Yacas runs on top of the Yacas scripting language, which is different from the languages in which the larger systems are implemented.

Another difference is of course that functions (algorithms) defined in these systems are built on top of other functions defined in these languages. It would thus at first seem that one can not simply take a small part of a system without taking the entire rest of the system with it.

This chapter addresses the first problem, the one where the algorithms are already defined in other languages, but with a different syntax. A simple scheme is presented here that will hopefully allow conversion of algorithms written in a certain syntax to the Yacas syntax. The aim is to preserve the structure of the original files as much as possible. Comments should thus be left untouched. Because of this, standard parsing and compilation techniques are not fully usable, as these schemes usually throw away comments from code parsed in as soon as possible, and the intermediate data structures don't offer a place for storing comments with sub-expressions.

The potential is huge; hundreds of man-years of research and development went into the other systems, and it would thus be a big boost to Yacas to be able to use these facilities. For this the licensing issues with these systems need to be resolved too.

This document will end with a discussion of the second problem; being able to take over parts of other systems as opposed to having to take over the entire system.

There are two steps to converting code so that it can be used in another system:

Converting the syntax is usually a large and cumbersome task which, as this document will try to show, can easily be explained to a computer. The second step, changing the semantics, might require hand-work.


Rationale

This is an interesting project in the domain of Yacas for several reasons:


General approach

There are three steps to the process of processing source code as data. The three steps come close to the read-eval-print concept from LISP:

The general steps taken by the interpreter are as follows:


Applications

The applications are essentially encoded in the middle process, where input tokens are converted to output tokens. For the support of one programming language, the READ and PRINT steps will stay the same, but the EVAL step will depend on what the aim is. The possible operations that the EVAL step could perform include (but are not limited to):

Converting to another programming language is a difficult task, and the author is not aware of other projects that succeeded in this arena. There are alternative approaches; for instance one could simply write a parser that converts to an internal format, and write a layer of macros to emulate the other programming language. However, the chances are that some handwork will be required to get the code in the desirable form. In this case an initial conversion into a form that is accepted by the normal parser of the programming language already aids a lot.


Implementation


Organization of the source files

The files are organized as follows:

In general it should only be necessary to load the [language][operation].ys file. This file should include the file [language]reader.ys which in turn should include the file codetransform.ys.


Optimizers


Examples


Compatibility modes

The first step is converting LISP code to code that can be parsed by the Yacas interpreter. The next step is to get the code to run at all. An initial method for this is to define macros that 'simulate' the Common Lisp environment.

The second step is to convert the code to the native Yacas coding standards. There are two things to consider; the general coding standards of the entire system (including the use of the facilities provided by Common Lisp), and the coding standards used by isolated programmers. This is an issue since lots of programmers have worked on these large systems, in general. For this it might be necessary to write specific optimizers for specific routines, as opposed to optimizers for the entire system. The alternative is of course to optimize by hand.


Problems with Common Lisp code interpretation

There are a few problems with Common Lisp that make it difficult to emulate it inside Yacas: