The original is in german. Please use the original documentation in the downloaded pack. This document should only be used to get an overview.
Any new paradigm in programming needs examples. The functional programming paradigm appears in the '80s and reaches it's most popularity with the language “Haskell”. Many alternatives exists in modern Lisp dialects like “Scheme” and others. All of them have more educational purpose than practical project realization.
Alaph is oriented at practical programing, combined with established paradigms. The basic approach is interactivity, followed by simplicity. Another aspect is freedom in the use of a native language.
The formulation of every cortical process for problem solving underlies native language. This implies syntax and grammar and finds it's mathematical end in naming and notation. There is no syntax and grammar in the Aleph concept, so the user is free to use his favorite language(s). On the other hand, the user is much more responsible for his formulations. No given rules means not everything is permitted. The user must realize the given problem and form out the specific rules. After that the programming can start, but with user/problem given rules.
An other problem with any new language is the vocabulary. Aleph has a very small active vocabulary but a giant passive one. The potential goes up to any reachable Java class. So the basic vocabulary is the Java installation in the used computer. Nevertheless the programming with Aleph is not even Java programming. It is the consequent use of mathematical compositions, used for functional objects.
To give a very small view to the potential, the following examples are created. The first example (roman numbers) has a educational relation, but the transfer to practical problems is simple. The second example (gui) is much more extensive and thought to show a lot of code for own experiences.
After download and unpack aleph.zip start the Java program aleph. Open a console (DOS-Window), change into the directory which includes the unpacked aleph.zip and
if Java is installed system wide type
java testV2M
If Java is installed locally type
LINUX user
/home/user/.../jdkXYZ/bin/java aleph
Microsoft user
/.../jdkXYZ/bin/java aleph
Where the three dots stands for the java installation path.
If a window with a white colored field and two buttons appears, the second example is still running. This is a simple GUI and is used to make the first steps with Aleph.
To start the first example simply type
"roman.vvm” load
and click the start button. The result is displayed in the console (DOS-Window). To understand what happened please read he following descriptions.
To convert roman numbers to decimal, the first problem is to find the patterns. In this example the given number is MMVII (2007). Instead of start the programming, the problem is viewed from an other perspective.
Perhaps a roman teacher gives the MMVII problem. The pupils must know the valuable patterns, split the given number into the patterns and add all the values. This was the way 2000 years ago and should be the way today. So the patters are the first problem.
The possible patterns are arranged in “groups” to have a relation to the associated values. The values are given in []-brackets, the corresponding patterns are simply strings.
The single groups have have a length order, given by the containing elements, first and then a value order.
[ 1, 2, 3]: "I" "II" "III"
[ 5, 4, 6, 7, 8]: "V" "IV" "VI" "VII" "VIII"
[ 10, 9, 20, 30]: "X" "IX" "XX" "XXX"
[ 50, 40, 60, 70, 80]: "L" "XL" "LX" "LXX" "LXXX"
[ 100, 90, 200, 300]: "C" "XC" "CC" "CCC"
[ 500, 400, 600, 700, 800]: "D" "CD" "DC" "DCC" "DCCC"
[1000, 900]: "M" "CM"
In normal programming this is a associative data structure to put all the values into an array (or a stack) and add all items. In V2M programming it could be done by the same way. But the way in functional programming is different. There are no variables (it shouldn't be) and of course no arrays of variables. Here any pattern is interpreted as a special add-function. These functions (commands) are
: viii 8 + ; : lxxx 80 + ; : dccc 800 + ; |
The function names are in lower case. The reason (for now) is not only to make a separation from the patterns.
All this commands are binary. To make an addition, at least 2 arguments are needed. To test the viii command the sequence is “0 viii .” with the result 8.
There one pattern that was not mentioned – 0 (zero). It was unknown in the past, but is needed in the actual problem. Like the test of viii a 0 is pushed onto the stack. Now all possible Patterns are pushed too.
There is an order in the pushing to guarantee correct replacement. The order is given by pattern length and associated value. After pushed all the patterns, at Top of Stack (TOS) lies “CM”. This is the longest string in the group with the highest values.
All push work is done by one command named init. It looks very far from functional programing, because there is only one value, followed by strings. This is only the first impression. In V2M no literals exists. So a directly given value (number, string, ...) exists only with an individual identity function. The Command init is only a collection of such identity functions.
: init |
The strings represents the knowledge of what must be separated, the order (reversed, because stack) represents the when.
Now everything is prepared to calculate the decimal value of a roman number except a roman number itself. The missed string is red directly from input, using the word command. After reading a string object with the roman number inside is at TOS (the flag if string exists is ignored in this description).
The following listing is the kernel of solving the problem. In this loop all patterns of the roman value are replaced. The string object str holds the patterns in upper case and no separation. Under this object all single patterns (ROMs) are on the stack an a numerical 0 is most down. This is the stack situation after the command init and red the input MMVII.
1: |
: dezimal |
In the comments in the listing the stack situation before and after the command is shown. ROM means a single roman pattern, ROMs means all remaining patterns, str holds the roman number with the separated patterns from left to right.
Line 2:
The upper element of the ROMs patterns comes to TOS. At first time this is “CM”, because it was the last pushed by the init command.
Line 3:
The lowcase command transforms the ROM to its lower case, followed by one space. This object is named rom. At first time the ROM is "CM" whith results in the rom with the content "cm ".
Line 4:
Simply arranges the objects on the stack to have them in correct order for the following command.
Line 5:
Replaces all occurrences of ROM to rom in the object str. If ROM doesn't occur in str, the unchanged object str remains at TOS.
Line 6:
Tests if there are more ROMs to be done.
After the loop is finished the object str contains separated roman numbers in lower case. Now all separated patterns should be evaluated. If there is a conventionally language this is the normal way.
But V2M isn't conventional.
To finish the work all corresponding values of the patterns in str must be added. But every pattern in str is a command too. So the object at TOS is an executable program sequence. The program has written a new program that is specialized only to solve the given problem. If this specialized program is executed, only the result appears on the stack. The generated program consumes itself. To start the program in str and keep the usability of the origin state, some suppositions must be given.
The V2M must execute the sequence like any other single command.
The originally input stream of program code must be saved and, after the process is done, restored.
This is a mechanism similar the file handling (see example GUI). But here an other technique is used, to show simple alternatives.
There is a reader in the V2M to get all the input. If the simple GUI is used, the reader is the string in the TextField. The access is done with
"inp" environment fetch // str 0 --> reader str 0 |
In the environment (the actual used V2M) the field inp holds the actual reader. The content is pushed onto the stack by the function (command) fetch. To put this object under str and 0 simply the commands
rot swap // str 0 reader |
are used. Now the sequence in str must be extended by commands to restore the reader.
Restoring the reader is simple as accessing. All what to do is to append
"inp" environment store |
as a string at the end of the sequence stored in str. Some other problem occurs, the V2M parser has no possibility to define a string like "\"". So the formulation of "inp" (including the quotes) is done by the command quoted. The other problem is the stack situation just before restoring the reader.
Assumed the sequence in str is processed. Then the stack situation is
Stack=[ number reader ] |
The reader must be at TOS before the additional restoring sequence can work correctly. A simple swap, as first command of the restoring sequence is all what is to do.
Now all the commands can be added (concatenated) to the existing sequence in str. Instead of the stack situations now the contents of str is shown as comments.
"swap " // "swap " "m m vii " |
Now, after calculated the value of the roman number (m m vii), the V2M reader is restored with swap "inp" environment store and only the roman value is on the stack.
Now a usable reader out of the completed sequence in str must be created. Java has classes and methods to do that, but in the V2M an appropriate method exists. It includes all the exception handling and can be used just like the field access that was used to access the reader.
environment "reader {Object}" call
|
The first line takes the string object at TOS and return a reader object. The argument type is Object, to use this method for other readable objects just like files. The second line simply stores the reader into the V2M field named "inp".
To handle all the commands in the new reader, the V2M must be informed that there is something new to process.
environment "process { }" call
|
After the last command in the new reader is done, V2M returns to the saved reader and continues at the last position. This position is exactly behind the call command that called the process method.
This example showed how different from conventional programming V2M can be used. Only scripting languages like JavaScript allows programs to write programs. What the V2M makes it also different to this is that V2M is a compiling language with the possibility of interpretation.
Moreover the accessibility of any 2M component was shown. So it should be easy to realize own techniques of local handling, sight and encapsulation. For friends of conventional lists of parameters and/or arguments local stacks for any command can be defined.
One of the important things in this example is the absence of variables, constants or any other unfunctional elements. In the next example the use of a variable is shown. This is because V2M has variables, but it's use should be minimized.
This part shows the use of files and subsystem classes. It begins with the only Java code, needed to start the GUI.
public class testV2M {
|
The V2M input gets a reader, including a string with the file name and a load command. Next and last instruction is to process the intup. The file is a simple text file. The additional ".vvm" is optional.
The following listings have the stack situation in every line. This may be helpful to start V2M programming, but it produces very large source code. The typesetting is a little bit smaller to show all the comments.
First a frame window is defined. The title is "basicGui" and pushed onto the stack. The instantiation of the window uses the creator method with the title as an argument. So the class of the frame is the next. The command classify uses the class name and pushes back the class for frame windows.
"basicGui" // --> str |
Now the arguments for the used creator must be specified. Without this it is impossible to find the creator method. With "{String}" the following (frame) creator is informed about the arguments type and pushes back the specified creator method. With the command build the titled frame object (frm) is available on the stack.
Some additional work should be done. To exit the application by closing the windows the "EXIT_ON_CLOSE" value must be given to the default close operation.
"EXIT_ON_CLOSE" // frm --> str frm |
All this must be done for the object "frm" on top of stack. So the (property) field "EXIT_ON_CLOSE" is fetched. The content of this field is used as an argument for the object method "setDefaultCloseOperation" . After calling this method, application end with closing the window.
Some Components should be inserted into the window. The easiest way is to fill a panel and let this be the new content pane.
"gui_en/panel.vvm" load // frm --> pnl frm |
In a file named "panel.vvm" the panel with all components is defined. Here only the frame window is relevant. The loaded panel is made the new content pane by calling the frame method "setContentPane". The rest is to pack all components and show the window.
The last line of this file brings some action to the buttons. This will described after all components are placed.
First a panel instance must be created. This is done with
"javax.swing.JPanel" // --> name |
This container needs a layout manager. To keep it simple border layout is used. Any layout is bound to a container with the file "layout.vvm". The code is described separately.
The only interesting thing here is the container and its structure (not the containing components).
"java.awt.BorderLayout" // panel --> name panel |
The border layout is bound to the container with the loaded file. The file could be a command, but the purpose of this example is to show the use of files.
"CENTER" // pnl --> str pnl |
Files can be used analog to commands. In some cases this is useful. Whatever, here this technique is used to avoid typing same sequences over and over again.
The structure to insert a component into a container is where must what be inserted. Each of this three parts is coded in a file with the given names. So it is just a reusable composition of some commands (functions). The compositions are used again to insert a button panel.
"SOUTH" // pnl --> str pnl |
The panel is done. In the file "baseGUI" it is made the new windows content pane.
Purpose is to provide a stack situation for the insertion of component(s). In the last parts the location ("CENTER", "SOUTH") was given by a string str. To make the listing more transparent str is substituted by location.
over // location pnl --> pnl location pnl |
The actual layout manager is pushed back from the method "getLayout". From this instance the field (property) with the name that location stands for is fetched. This is the place where the comonent(s) will be inserted.
A component named "what" is inserted with the following sequence. Simply the method "add" is called.
swap // what pnl where pnl --> pnl what where pnl |
But the called method isn't void. The component is returned and so pushed n the stack. Therefore a drop must be done to make the sequence consumptive.
Now all is ready to insert components. The following listings have the sequences to do that.
Here a break with the FP paradigm happens! A variable is used. The use was made to keep coding clearly.
The input area is realized with a JTextArea. To have some editor features a JTextPane or JEditPane should used instead. Whatever, the component itself has no relevance for the description.
"javax.swing.JTextArea" classify instantiate // --> inp |
Creates the instance of an input area.
This component is used in the button actions, which are described later. It is possible to keep this instance on the stack till programming the button actions. But the example should be readable.
variable input // inp --> inp |
The field is stored in the variable input. Here it is save and does not confuse the stack situations.
The input area named inp needs an own font. To have a pool of sequences for use in files or commands, one more file (font.vvm) exists to bind a font to components. Here is shown directly in the code.
"Monospaced" 0 12 // inp --> [parms] inp |
The parameters [parms] to instantiate a new Font are "Monospaced", 0 and 12. The rest of this code snippet is trivial. With
over // font inp --> inp font inp |
the font is bound to the input field. Now 70 columns and 20 rows are set to define the bounds of the input field.
70 over // inp --> inp cols inp |
Because the input could be larger than the defined columns and rows, a ScollPane is created for te input area.
"javax.swing.JScrollPane" // inp --> name inp |
The instantiation uses the input area inp as its argument. Now the input component pane is ready for insertion, showed in the listing before.
To make the GUI display complete, a Panel with two buttons is defined. Again a break with the FP paradigm happens! Variable are used.
The definition of buttons have an own sequence in a file named "button.vvm". The sequences are inserted here directly, just like font definition. First the panel instance.
"javax.swing.JPanel" classify instantiate // --> panel |
Now the instance of the "Start" button, followed by setting its text "Knopf" by using its method "setText".
dup // butt panel --> butt butt panel |
Don't be confused of setting "Knopf". It's the german word for "button" and used to mark buttons without action. Action handling is done later in this example. So the button is stored in a variable for further using.
variable button1 put button1 // butt panel --> panel |
Later is relative. To add the button as a component into the button panel, the variable is used right here.
button1 over // panel --> panel butt panel |
No layout manager must be defined, because using the default flow layout. The second button is simply a copy and shown only for completeness.
dup // butt panel --> butt butt panel |
The second and last component for windows content pane is ready. There is only one thing left, action.
Actions are event oriented. The V2M per se is not. To make actions available for the V2M a small Java file "vAct.java" was defined. This code is the base to bind an action listener to components.
The code will be integrated into the engine in one of the next versions. For now it is only an additional tool.
1: |
public class vAct extends AbstractAction {
|
The creator method simply sets the name of the action and stores references to the virtual machine and a command (lines 12 ... 14). Interesting is only the method "actionPerformed".
If an event happens, the runTime part (method) of the command is started. The command must push back a string (line 6). In line 7 this string is declared as the new reader for the machine. The content of the string is taken as a V2M sequence and processed in line 8.
The actions for the buttons are defined in this file. Some things may be strange for programmers using conventional languages. First some manipulations on the V2M properties are done. This is, because there is a flag "shwcp" that must be toggled. It indicates a listing of new command definitions to the console. This shouldn't be happened while creating the GUI. In the following listings the flag is ignored in stack situations.
"shwcp" environment fetch // --> flag |
Now the needed commands must be defined. First the start command. The engine needs a reference to the typed source code. So the action listener of the start button has to do that. To keep it simple a command is defined.
: start |
The variable input is just a symbol for the input field. calling its name pushes back the object. So the method getText is used to push back a reference to the typed source code. Keep in mind that this was only the definition of a command, It will never be used by calling its name.
Next an action listener is created. The vAct creator needs some arguments, which are pushed first.
"Start" // --> text (Buttons Text) |
The start command was defined just before. So the true is not really significant and dropped from the stack.
"engine.vAct" classify // cmnd v2m text --> class cmnd v2m text |
This simple instantiation sequence needs no more description. Stack situations are also minimized. Binding this action to the button is done with
button1 "setAction {javax.swing.Action}" call // action -->
|
The second button needs a command too. This button will only clear the input area. The definition is
: clear |
First a empty text is set to the input field to clear it. Then the focus is set to the input field. Last a not needed string object is pushed back. This is, because in vAct a reader is made out of this object.
The binding is analog to the start button.
"Clear" // --> text |
Ready!
But not clean. A flag was ignored, it is still on stack.
"shwcp" environment store |
Variables and commands where defined. Nobody needs this. The dictionary (vocabulary) should forget this.
forget input |
Forgets all variables and commands define since input, including input. Now a GUI for the V2M with clean stack and clean dictionary is really ready.