AlMuist's API introduction

As said in the introduction, Amool was created for AlMuist's, a graphical programming environment.

So, now that the language has been defined, I have to define a set of classes that allow creating programs. I will first enumerate everything I want this interface to be able to.

Multiple language support

AlMuist's must be able to generate code in any language. This will be achieved with the language hierarchy.
There are things that are valid for all languages, that will be at the top of that hierarchy.
Then, some things can be for instance common to some languages. (for instance, as Java and C are quite similar syntactically speaking, you might want to define that syntax only once for them)
And then there are things that are specific to one single language, but that do not depend on the compiler/implementation.
And finally there are some points that might be specific to one special compiler for a given language

So this is defines the language hierarchy. I will implement it as a hierarchy of classes that inherit from the above ones. When you write a program, you will then subclass the language you chose.

Components willing to write language independent stuff will be able to add children referencing the syntaxes inherited from the language. For instance, a component might want to add a variable to the program, so it will do something like this:
&+'program.variables &=super @parent.variable &&
&=name dong &&
&=type @parent.int32 &&
&&

The generated code would look like this, depending on what language the program is subclassing:
AmigaE : DEF dong:LONG
Java : int dong;
Ada : dong:Integer;
(and so on)

As much language independence as possible

This is not a specific goal as above. In words, I want to have as much classes containing no language specific stuff as possible. For instance, Amool classes corresponding to Mui classes must not have any language specific code. This means that I need to have classes defining what a procedure (or subprogram, etc) is, so that a highlevel class can specify the creation for a procedure without still being language specific. The same for types, structures, ...

This implies two things:

1. for adding a new programming language, there should be as few work as possible
2. adding a language independent stuff would allow to code it once and make it available for all languages at once

Generation of multiple files

Quite obvious, there must be a way for a class to generate more than one file; in Java it should return one file for each class, in E it should return one file for each module, and so on

This has to be implemented, I believe, in the Amool compiler and not in the language itself. When you are compiling your code, you can either want one class to be compiled (Which generates one file), or some of its children (which generates as much files as there are children.)

Physical separation of the gui and the core

I'll come back later on this point. I want here to have, in every program (subclass of some @program class) some children that define the core, and one child that define the gui.

When I say physical separation, it means that the programmer must be able, with one single switch change, to have, after compilation (by the amool compiler and then by the language compiler), one file that is the executable file, that contains no definition of the gui, and another file that contains the gui, which can therefore be changed without touching the program itself.

Of course, when that little switch mentionned above is not active, the compiled program should contain both the core and the gui. I will explain how this is implemented in the next chapter.