The idea behind this project is to create a multi-headed beast of an interpreter that contains within it interpreters for each of the supported heads. At present this is little more than a research project. For a practical 'multi-scripting' system see Minotaur. Minotaur is part of a larger colossus project. Discussions surrounding this project combined with several existing seeds (or should I say teeth?) inspired this work. At present the goals of the hydra project are as follows:
We refer here, initialally, to a implementation language side interface rather than the requirements of the language itself (those define the differences between languages by their very nature as will be investigated later). In other words, we are trying to generalise methods embedding and using interpreters. For convenience sake we use "C" as our implementation language, though it could be anything. The Minotaur project, for example, achieves much of its functionality through using forth as a glue language. When an attempt is made to embed multiple language interpreters in a single executable, it becomes clear early on what the basic structure of this interface must include:
This much is obvious. Even at this level there are noteworthy features to consider. While any embeddable interpreter must provide an eval method we can still ask useful questions, such as thoe that follow. Note also that there is no reason why any compiled language could not be implemented as an interpreted language or indeed include an 'eval' method. It is in this broadest sense that the term 'scripting language' will be considered. The author would very much like to hear of implementations of a C interpreter and or C eval function (a basic but useable implementation would invoke the compiler to generate code which is then linked into the running executable).
And these are only the most basic questions on the zeroth tier of language. At higher tiers there is scope for much more. It would be exceptional (though not impossible) for an interpreter not to support some basic procedures for manipulating strings & numbers. File handling is essential for a general purpose language aimed beyond applications such as webpages, and even here a limited subset is useful. All these areas can be considered and possibly generalised into the basis of a general theory of programming.
This part of the project aims to create a checklist for each of a variety of categories. Which languages provide regular expressions and which support complex datastructures, for example. Further points giving more detail at lower levels will also be developed. Some measures of the complexity and efficiency of each implementation will also be given. This information will be used to develop a system of interface specifications which will be useful in writing more portable code and selecting languages most appropriate to an application. It will also serve to demonstrate a general method that can be applied to libraries and components of arbitary complexity. It will also highlight defficiencies in existing implementations and hopefully stimulate their maintainers to address them. Another of the goals is to develop meta-algorithms to define a given algorithm or primative of one language in terms of the primatives availiable in another thus creating a system capable of meta-programming algorithms into any target environment.
Static linking is a useful goal in the sense that it allows applications to be distributed as a single monolithic executable. Dynamic linking is in many ways easier & more useful as it allows code to be shared between applications and makes upgrading easier (though with impact to version control). Both methods have their place. In the case of this project static linking is useful in demonstrating which languages are implemented in a way friendly to the embedder and which are not. For example TCL and Python prefix almost all their symbols, including functions, with the prefixes Tcl_ and Py_ respectively. This makes combining both in a single interpreter relatively trivial. Registering a prefix for a given language seems to be the way to go. However, the nightmare of many languages each defining their own version of say a string struct is not far away. It may be necessary to find or develop a tool to remap the symbols used by a language to match this specification. A better interpreter capable of dynamic linking can be developed once the minimal interface has been defined and grafted on to each participating language. With further development common features of many languages could be abstracted into a core scripting kernel. This is one goal considered by the collosus project (no links are available at this time).
The project aims to include as many languages as possible. Initially the target set is limited to those commonly defined as scripting languages. This target set is further reduced to give priority to languages bearing the greatest similarity to each other (and familiarity to the author). Currently the three main heads are TCL, Python and Perl. The following languages are also being considered for inclusion; lua, Java, ici, s-lang & lisp. In this case, java is being considered expressly because it is different. If an object oriented language such as java can be combined with a conventional 'scripting' language, which has been demonstrated successfully elsewhere, then pretty much anything is possible. The author will also consider any other languages that he hears of or is asked to for which a public domain implementation is available.
A working interpreter has been developed that can successfully run hello world programs in each of the three primary heads (i.e. TCL, Python and Perl). There is at present no interaction between the interpreters. The approach being taken initially, is for hydra to act at a macro level redirecting lines of a script to each interpreter. This mechanism is of only limited applicability, for a more practical implementation you are advised to consider minotaur.
Please note this example (which actually runs!) is unlikely to bear any resemblance to a future more practical implementation, though suggestions for such a design are welcome.
HYDRA COMMENT : This is a hello world program for all heads HYDRA PRINT Hello World! HYDRA DEFAULT TCL puts stdout "Hello world from the TCL head (default)" PYTHON hello="hello world from the python head (not default)" PYTHON print hello PERL print 'hello world from the perl head (not default)' HYDRA DEFAULT PYTHON hello="hello world from the python head (default)" print hello TCL puts stdout "Hello world from the TCL head (default)" HYDRA DEFAULT PERL print 'hello world from the perl head (default)' HYDRA PRINT Goodbye world!
This research is currently unfunded and being untaken solely by the author Bruce S. O. Adams (in my spare time), though an awareness should be made of related projects. The results are to be made public domain and used to enhance further developments in the language arena. Anyone wishing to fund or contribute to this research should contact the author directly.