ELENA Programming Language blog

Dynamic Programming in ELENA

2012-02-01T03:54:00.001-08:00

Last year I demonstrated how to create BF interpreter without writing any program. But to implement a loop I still had to create a new class (in runtime). After a while I realize that it is possible to get rid of auto code generation completely, using only special group types (except for dynamic subjects).

Let's start with general overview of dynamic programming paradigm in ELENA. Instead of writing a code (with the help of run-time compilation or some built-in functionality) we could build (assemble) a new object reusing existing functionality. Subjects and built-in verb roles will allow us to create new methods and invoke them (without any kind of reflection mechanisms), different group objects (wrap, echo, cast, prop and action) will combine them to implement the program logic.

Presume we would like to create a dynamic code which will execute the following bf code: , [ . , ]

First of all we have to create a tape:

anIndexer := factory'NewArray::{ &factory'array_size:1024 &factory'pattern:(WideCharVar::0) } @ 0.

Now we have to add a new dynamic method to the indexer which executes the loop until the current item is zero. So we create a group and add the indexer into it:

#var aGroup := sys'dynamics'GroupVariable append &sys'dynamics'group_member: anIndexer

Our dynamic method will need its own subject:

#subject bfloop.

Let's create the method:

aGroup append &sys'dynamics'group_member:__prop(bfloop, __run, __wrap(EWhileNotZero, aGroup)).

In this code we use two types of group objects:__prop and __wrap. __prop is a property collection which consists of a subject symbol (bfloop), a wrapper (verb external role) and a content - another wrapper. The property converts a qualified message (bfloop'invoke) into a generic one (invoke) and sends it to a verb role. A verb role in its turn sends the appropriate message (run) to the property content (__wrap(EWhileNotZero, aGroup)). The created group is equivalent to the following code:

aGroup append &sys'dynamics'group_member: { bfloop'invoke : anAction = self~EWhileNotZero run:anAction. }.

To implement input / output operations we will use the following actions:

#var anOutputAction := __wrap(__write, 'program'output).
#var anInputAction := __wrap(__save, __action(__get, 'program'input, nil)).

The "traditional" code looks like this:

#var anOutputAction :={ invoke : aGroup =  'program'output write:aGroup. }.
#var anInputAction :={ invoke : aGroup =  'program'input get save:aGroup. }.

Note that once again we use verb roles to translate invoke into write and save respectively. anInputAction is a bit more complicated. We need to implement the action before invoking save message. That's why another special group - __action - is used.

And finally we combine these actions:

__cast(anInputAction, __echo(bfloop, __wrap(__eval, __cast(anOutputAction, anInputAction)))) invoke:aGroup.

Which could be translated into the following code:

__cast(anInputAction, { invoke : aGroup =  aGroup invoke &bfloop:__cast(anOutputAction, anInputAction) }) invoke:aGroup.

As you can see we were able to create an object with a custom method without actually declaring a new class. Of course this approach is not suited for programmers but it could be used for automatic code assembling inside the program in run-time, for example in ELENAVM script:

tape       =>
              // 1: append
              &subject 
              // 2: goto
              &subject
              // 3: loop
              &subject
              // 4: inc action
              &1 1 &echo
              // 5: dec action
              &1 -1 &echo
              // 6: next action
              &2 1 &echo
              // 7: prev action
              &2 -1 &echo
              // 8: output action
              &__write &nil 'program'output &wrap
              // 9: group
              &nil
              sys'dynamics'groupvariable
              &std'basic'factory'array_size &sys'vm'routines'egetprop 1024 &prop
              &std'basic'factory'pattern &sys'vm'routines'egetprop 0 std'basic'widecharvar &prop
              &union2
              std'basic'factory'patternarrayfactory
              std'basic'factory'newarray 
              0 ^refer 
              ~ sys'dynamics'group_member ^append
              // :: append method
              &1 &__append &9 &prop
              ~ sys'dynamics'group_member ^append
              // :: goto method
              &2 &__append &std'dictionary'index &9 &wrap &prop
              ~ sys'dynamics'group_member ^append
              // :: loop method
              &3 &__run &std'patterns'ewhilenotzero &9 &wrap &prop
              ~ sys'dynamics'group_member ^append
              // 10: in action
              &__save &__get &nil 'program'input &nil &action &wrap
              // build command batch
              &cast
              $body
              &9
              ^ invoke;
inc        => &4 |= $body;
dec        => &5 |= $body;
next       => &6 |= $body;
prev       => &7 |= $body;
out        => &8 |= $body;
in         => &10 |= $body;
while      => &3 &__eval &cast $body &wrap &echo |=;

New Group Types

2012-01-05T03:10:00.000-08:00

The latest 1.6.12 release contains several critical changes in the way how the language works with group objects and subjects. In this article I will cover some of these changes.

First of all I made several cosmetic changes: the class extension keywords - #annex and #union were renamed to #join and #outer respectively. Group keywords #group, #union and #cast are no longer supported, built-in classes should be used instead. And a generic handler (#generic) was added.

Detailed discussion we will start with class extensions: #join expression. #join extension can be used both inside the class declaration and as a part of the inline (nested) class expression.

#class MyClass
{
    ...

    #join EMyExtension.
}

If the keyword is followed by an external role (or a stateless class) it is used for "horizontal" inheritance. It is roughly similar to the multiply interface inheritance (note that the class "parents" should not have their own fields).

#class MyIndexer
{
    #field theItem.

    ...

    #join theItem.
}

But the joining expression can be a normal object (e.g class field) as well. In this case it is similar to the group object and is used for run-time extension (permanent dynamic mutation). For example it is used in ELENA indexers to extend the collection item with navigating functionality. Note that in both cases "self" built-in variable refers to the extended class instance (so it is similar to a group object).

'program'output << #join(anObject) { literal = "object:" + anObject literal. }.

In this case the inline class declaration can be used as well.

Now let's go to #outer (join) extension.

#class Variable
{
    #field theValue.

    #method content = theValue.

    #method content'set : aValue
    [
        theValue := aValue.
    ]

    #outer theValue.
}

Outer join extension can be used only inside the class declaration and in most cases is used with objects. The main difference with join extension is that "self" variable is not overridden. This type of extension is used mostly in containers (a dynamic variable).

#class MyClass
{
    ...

    #generic
    [
        'program'output << "My class does not support this method".
        $self fail.
    ]
}

#generic extension is a special method which is called for any unhandled message.

Now let's go to the main topic of this article: group objects. We will start an implicit group object. Before I will continue let me remind you what is ELENA group object: a collection of the objects accessible through the common instance reference (see here).

#var aSecond := aList~EItem @ 1.

A group object is used to dynamically extend the existing object with a new functionality (some kind of mutation). For example in this case we extends the collection with an ability to return the collection member by index. A group can be temporal if the group is immediately followed by a message and the mutator is an external role or a stateless class.

The group can be created explicitly with a help of built-in class - __group.

#var anExtendedList := __group(EItem, aList).

Note that in this case the group is always permanent.

Another way to temporal extend the object is a wrap group (__wrap built-in class)

#var aStr := WideStrValue::__wrap(EInt32Variant, aNumber).

A wrap is a special group which uses the first member of the collection as a wrapper around the second one (content). It means that only the wrapper methods are invoked but "self" variable is assigned to the wrap content. In most cases the wrapper object should be a role or a stateless class. Note that a wrap should have only two members.

Before we will continue with other group types, let me say a few words about subjects. As you may probably know in ELENA language the message consists of message subject (actually a message namespace) and a message verb (built in list of names such as get, set, add, append and so on). A subject should be declared before use. Simultaneously a special symbol (named expression) with the same name is declared. Due to this the program could handle a subject like any other program element (without any kind reflection).

#var aProp1 := aObject subject'get.
#var aProp2 := anObject~subject get.
#var aSubj := subject. #var aProp3 := __wrap(aSubj, anObject) get.

Both these expressions are equivalent but in the third case actually a variable referring to the subject symbol is used.

A special case of the wrap group is a property collection (__prop built-in class)

Compare these two equivalent expressions:

#class egetadapter
{
    #method get = self.
}

...

#var anArray1 := NewArray::{ &array_size:1024 }.

#var anArray2 := NewArray::__prop(array_size, egetadapter, 1024).

The property collection consists of a subject symbol, a wrapper and a content. When a message is sent to the collection the property handler checks its subject and if it is equal to the property subjects the generic message (only the message verb) is sent to the wrapper with "self" variable assigned to the wrap content. As you may see the property collection is similar to the "traditional" class property. Note that in this case no new class is declared and the subject could be dynamic.

And our final group type is a union (__union). Union (similar to outer class extension) could be considered as a collection of dynamic variables.

#var anArray1 := NewArray::{ &array_size:1024 &pattern:integer::0 }.

#var anArray2 := NewArray::__union(__prop(array_size, egetadapter, 1024), __prop(pattern, egetadapter, integer::0)).

What's new in 1.6.6

2011-11-08T04:27:00.000-08:00

In this post I would like to discuss some things done in 1.6.6. The migration of ELENA code base to LIB2 (and simultaneously to GCX ) was finally completed. Up'N'Down sample (the most complicated program written in ELENA so far) is now playable again. As a result I was able to continue work on ELENA library. So I would like to present two new classes (actually external roles) introduced in 1.6.6: std'patterns'esort and std'routines'estrop.

First of all I have to remind some basic things about roles and groups. A role is an alternative set of methods which can be used for context-dependant programming. The role cannot have fields so it could be considered as stateless class. There are two types of roles: internal and external ones.

A group is a collection of objects sharing the common instance variable (self). The group is used for dynamic code extending. We could consider it either as a JIT (just in time) inheritance or as a code mutation. For example if I would like to add or override the object method I could extend it by creating a group with my custom object containing the required code. The given group will be practically identical to the original object and could be used instead of it.

So if we would like to apply the role to the object we could actually group them. For internal role it is done with a help of #shift statement. For external we should declare the group ourselves with tilde operator (in reality it is a bit more complicated but I will simplify for the sake of clarity).

So far so good. Now let's turn to our new classes (roles). std'patterns'ESort is used to extend any collection / array with sorting functionality. Here some examples how it could be used:

#var a := (1,7,4,-5).
a~esort run: aPair => (aPair former < aPair later).

#var b := ("b","ab","a","aa").
b~esort run: aPair => (aPair former < aPair later).

#var c := list += 3 += -4 += 1.
c~eindexeditem~esort run: aPair => (aPair former < aPair later).

#var d := list += "b" += "av" += "a".
d~eindexeditem~esort run: aPair => (aPair former < aPair later).

Note that std'routines'EIndexedItem extends any collection with "@" operator (used for array-like access to its members). Run method sorts the collection basing on the provided expression.

Our another role - std'routines'EStrOp extends the literal value with some basic string operations like find, insert, delete and substring.

#var p1 := "abba"~estrop find &first:"b".
#var p2 := "abba"~estrop find &last:"a".

#var s2 := "abba"~estrop replace &from:"b" &to:"B".
#var s3 := "abba"~estrop replace_all &from:"b" &to:"B".
#var s4 := "abba"~estrop substring &from:1 &to:2.

#var s41 := "abba"~estrop substring &from:1 &length:2.

#var s5 := "aa"~estrop insert &literal:"bb" &index:1.
#var s6 := "abbba"~estrop delete &from:2 &to:2.

ELENA Engine: Sections, references

2011-10-03T01:57:00.001-07:00

When I started developing my language I was interested in creating a compiler from scratch without looking into other implementations. So some of my solutions may look unorthodox. Nevertheless the linker is the most "old" part of my code. Once made that decision I stuck with it.

Any compiler may be split into several parts: a parser, a code compiler and a linker. In general a parser parses the source code, a compiler generates the output code and a linker assembles this code into executable file. From the linker point of view the program code consists of sections connected with each other by references. The section may contain both an executable code and data. The output sections usually are saved into temporal files, which we could call compiled modules (or simply modules).

In ELENA the situation is a bit more complex. The modules may contain native executable code (in this case this module is called "primitive" and generated by external tools, for example asm2binx) and ELENA byte codes (ecodes). So ecodes should be converted into native codes with a help of Just In Time Compiler (JITCompiler & JITLinker in ELENA Engine). It could be done in the compiler (elc) itself or in a virtual machine (elenavm) right after the module is loaded (hence the name - just in time compiler).

Now let's discuss ELENA compiled module (.NL file). We could consider the module as a list of data (sections, messages, constants). To help the linker find the required data, every list item has a unique (within its module) identifier - a reference. A reference is a 32bit integer, where the highest byte contains the reference type (see elenascr2\engine\elenaconst.h :: ReferenceType) and the rest is a reference number. The reference number has a corresponded literal identifier in the module reference table - reference name. The reference name consists of module and proper names. If the module name equals to the name of the current one it is the reference to this module, otherwise it is external one.

The code and data are saved into sections. Depending on the reference type the section may contain native code, data, VM byte codes, VMTs. In most cases the section has references to other part of the program or library. To support these external references every section is followed by a relocation table. The relocation table has quite simple structure: it is list of reference id and the address of the reference location in the section (relative to the section).

The module may contain messages (actually message qualifier - subjects) and constants. Every time a new subject is declared its name is saved in the message table and the appropriate reference is used inside the code. With the help of relocation table these ids are synchronized between different modules. The same happens with constants (numeric and literal). This allows us to have only one instance for every constant used in the code.

So how the linker works? Every program has an entry (or several of them in case of VM). Presume it is "sys'entries'simple". The linker loads the module "sys'entries" and finds the appropriate reference number (based on the module reference table). To load the required data we need to know the reference type. Presume it is a symbol reference (byte code section). Combining the reference number and the type we could find the required section. The reference type tells the linker where this section should be copied to, in our case to .TEXT (executable code). If it is a byte code (as in our case) JITCompiler converts ecodes into the native commands. Next the linker will go through the relocation table and load all referred data (sections, external functions, messages, constants and so on) and update the section body with the correct addresses and so on.

And finally I will provide the structure of .NL file:

ELENA module structure
-------------------------
a) General file structure:
+--------------+
| module stamp |
+--------------+
| module name  |
+--------------+
|  references  |
+--------------+
|   messages   |
+--------------+
|  constants   |
+--------------+
|   sections   |
+--------------+

b) module stamp - fixed-size module version signature (not terminated by zero)

c) module name  - zero terminated module name

d) references   - reference section 
+--------------+
|    size      |  total section size
+--------------+ 
|   reference  |
|     memory   |
|  hash table  |

e) messages
+--------------+
|    size      |  total section size
+--------------+ 
|   message    |
|   memory     |
|  hash table  |

f) constants
+--------------+
|    size      |  total section size
+--------------+ 
|   constant   |
|    memory    |
|  hash table  |

g) sections     - section list      

                 
{section}

where section = 
<section id>
<section size>
<section body>

<relocation table size>
<reference id>
<reference position>
...

ELENA Virtual Machine Script: BF interpreter

2011-09-20T02:55:00.000-07:00

In the previous post I showed some basic things about the terminal script. After several changes the current system of commands looks like this:

-q - quit
-h - help
-ton - trace mode is on
-toff - trace mode is off
-l[path] - load a script from file
-n[path] - load an inline script from file
-c[path] - load DSA script from file
-i[inline script] - execute inline script\n"
-g[dsa rule] - define dsa rule; they should be separated by a semicolon except the last rule\n"
-pX - select parse mode (0 - standard, 1 - simple)

Note that there are two parse modes: standard and simple. Presume we have to parse the following expression: "23 * 4". In Standard mode it will be parsed as three terminal symbols: "23", "*" and "4". But in simple mode every character will be a separate terminal symbol. This mode will be used in our BF interpreter.

Despite I called it interpreter it is actually just-in-time compiler. The script tape generated by ELENA Script Engine is translated into byte-codes and executed like "normal" code.

The DSA script looks like this:

statement  ::= next;
statement  ::= next;
statement  ::= prev;
statement  ::= inc;
statement  ::= dec;
statement  ::= out;
statement  ::= in;
statement  ::= "[" while;
statement  ::= idle;

next       ::= ">";
prev       ::= "<";
inc        ::= "+";
dec        ::= "-";
out        ::= ".";
in         ::= ",";
idle       ::= $any;

while      ::= statement while_r;

while_r    ::= "]";
while_r    ::= statement while_r;

tape       ::= statement statements;

statements ::= statement statements;
statements ::= $eps;

start      ::= tape;

tape       =>  &union
                  &group 1024 += &std'dictionary'count += *=
                  &group { 0 std'basic'widecharvar } += &std'basic'factories'onnew += *=
               std'basic'factories'newinitializedarray 0 ^refer $body;
next       => 1 &std'dictionary'index ^^append $body;
prev       => 1 &std'dictionary'index ^^reduce $body;
inc        => 1 ^append $body;
dec        => 1 ^reduce $body;
out        => &nil 'program'output &previous ^write . $body;
in         => &nil 'program'input &nil ^get ^write $body;

while      => &group
                &previous +=
                &std'patterns'ewhilenotzero +=
                { $body } ^run .;

As you may already know the script consists of two type of rules: grammar and DSA ones. Grammar rules allow us to generate a derivation tree and DSA ones are used to build the code (list of VM instructions, so-called a script tape) based on that tree. DSA rule is applied for the grammar one with the same name.

I think grammar rules are quite simple so we begin with DSA ones. The first rule which is invoked right after the start is tape. In this rule we create an array of widechar objects.

tape       =>  &union
                  &group 1024 += &std'dictionary'count += *=
                  &group { 0 std'basic'widecharvar } += &std'basic'factories'onnew += *=
               std'basic'factories'newinitializedarray 0 ^refer $body;

The equivalent ELENA code will look like this:

std'basic'factories'newinitializedarray::&count:1024 
&onnew: (=> std'basic'widecharvar::0) @ 0

Note that { 0 std'basic'widecharvar } is an action symbol (compare with => std'basic'widecharvar::0 in ELENA code). To pass several parameters to newinitializedarray we use a union of group objects.

&group 1024 += &std'dictionary'count += *=

is in fact equivalent to

{ count = 1024. }

where std'dictionary'count is a subject symbol, &group is an instance of the $elean'group class and command += adds the object to the group.

To understand how it works I will remind about subject symbols. Every time a new subject is declared the appropriate subject class is auto-generated as well. This class contains "subject'get" method returning self variable. A union is a week group type. It means that self variable points to the group member rather than to the group itself. So the following expression

#union(#group(std'dictionary'count,1024),#group(std'basic'factories'onnew,...)) std'dictionary'count

will return a count group. As a result this union of groups is equvivalent to

{ std'dictionary'count = 1024. std'basic'factories'onnew = ... }

Other rules are quite simple. For example rule next:

next       => 1 &std'dictionary'index ^^append $body;

is similar to

... index'append:1

Note that &std'dictionary'index is a subject symbol used as multiple dispatcher: ^^ is equivalent to &: operator.

And finally let's consider the simple echo program:

-p1
,[.,]

It will be translated into the following inline code:

@new $elena'$union
@new $elena'$group
@push 1024
@group-add
@push std'dictionary'count
@group-add
@union-add
@new $elena'$group
@sub
  @push 0
  @call std'basic'widecharvar
@end
@group-add
@push std'basic'factories'onnew
@group-add
@union-add
@call std'basic'factories'newinitializedarray
@push 0
@send refer
@push $elena'$nil
@call 'program'input
@push $elena'$nil
@send get
@send write
@new $elena'$group
@copy 1
@group-add
@push std'patterns'ewhilenotzero
@group-add
@sub
  @push $elena'$nil
  @call 'program'output
  @copy 1
  @send write
  @pop
  @push $elena'$nil
  @call 'program'input
  @push $elena'$nil
  @send get
  @send write
@end
@send run
@pop

ELENA 1.6.3 released

2011-08-01T15:34:00.000-07:00

ELENA 1.6.3 is out now

This release includes several language enhancements beta version of ELENA script engine, refactored LIB2 and beta version of GCX. All samples (except upndown) are migrated to lib2.

Other changes

@ operator parsing order is changed
#define import subjects as well
argument list is now possible to use with symbol parameter as well
nil subject is no longer supported, use nillable
several bug fixes

LIB2:Conversion to the string

2011-07-15T01:31:00.000-07:00

Being a pure object-oriented language ELENA does not support any built-in conversion mechanisms, objects should implement special methods themselves. A standard way to make the object convertible to the string is to implement literal'get method

#class MyLiteral
{
...

#method literal = "My Class".
}

...

#var aLiteral := MyObject literal.

If the object is a number it could implement a numeric protocol. In this case the code will look like this:

#class MyNumber
{
...

#method numeric = 5.
}

...

#var aLiteral := anObject numeric save: std'basic'WideStrConvert.

Note: std'basic'WideStrConvert converts supported numeric values (integer and real numbers) to the literal one.

Let's use more generic code. In this case we have to implement a conversion protocol.

#class MyLiteral
{
...

#method literal = "My Class".

#method request : anObject = anObject literal:($self literal).
}
#class MyNumber
{
...

#method numeric = 5.

#method request  :  anObject = anObject save:($self numeric).
}

...

#var aLiteral := MyObject request:{ 
literal : aLiteral = aLiteral

numeric : aNumber = aNumber save:std'basic'WideStrConvert.
}.

Note: request method is used to define the object supported "type" (either numeric, literal, indexable and so on).

Alternatively we could use existing symbol std'routines'PrintValue:

#var aLiteral := std'routines'PrintValue::MyObject.

In case if our object is a complex one let's consider a last example (see goods sample)

#class Record
{
#field theName.

#field thePrice.

...

#method literal
[
^ ext'text'TextWriter write:"Name:" write:theName write:" Price:" write:thePrice literal.
]
}

...

'program'output << MyRecord.

Note: if PrintValue symbol is used (e.g. in 'program'output) request method may be omitted if the object implements literal'get one.

"Weekly" release - 1.6.2.1

2011-07-09T11:17:00.000-07:00

This is a weekly service release. Note it is binary incompatible with the previous versions

-ffriend-injection mingw compiler option was removed
subject implementation overhaul
#define imports subjects as well
nil subject is no longer supported, use nillable
vm terminal refactored
fixed bug in asm2binx: __arg1 is not recognized as a reference for SUB
@ operator parsing order is changed
argument list is now possible to use with symbol parameter as well
script engine refactored

You may download it from sourceforge

Subject symbols

2011-06-27T13:13:00.000-07:00

As I mentioned in the very first post in this blog when I started ELENA project I decided that the best plan is no plan. After all it is hard to plan if you have only a vague idea of your future programming language. After ten years of development several distinct languages were developed (just compare 1.0.0, 1.4.6, 1.5.1 and 1.6.2) and the work goes on. So when people (those few who bother to look at) complain that ELENA is a weird or exotic they forget that it is an experimental language and it shouldn't be all shiny (at least until it is in development phase). Its main purpose is to check the proposed concepts. And at the moment it is an open architecture concept.

This model of development may be called evolutional (yes, in the evolution there is no plan as well). Similar to the real evolution some minor tactical decisions may have a great impact. When I came up with an idea of a message subject I tried to solve a practical question: how to write a real program if you have very limited set of message names. Later it appeared that the subject can be used to implement some kind of multiple dispatching in ELENA. And now (starting from 1.6.3) the subject will be used in VM script engine as a message adapter.

Every time a new subject is declared the appropriate implicit symbol is auto-generated as well (actually two symbols). When the symbol is called without an argument it returns an external role (stateless object) used to invoke a message, otherwise the property wrapper.

So let's look at several use cases. The first case is sending a message. Presume we would like to send a qualified message to the object. Usually it looks like this - anObject verb &subject:aParameter. With the help of the subject symbol we could implement the same code without using subject (remember it is not possible to use subjects in ELENA-script): anObject~subject verb:aParameter. In this code our subject symbol translates verb into subject'verb.

Secondly let's extend an object with a subject property: anObject~(subject::Variable), subject symbol returns a wrapper object around Variable which translates subject'get / subject'set into get / set.

Let's look how this concept can be used in vm terminal. Presume we would like to return the literal constant length: nil 'program'output "abc" nil nil std'dictionary'length &get will print 3.

One may ask why not to allow to use subjects in the script? Of course it could be easily done but in this case there is no need in subjects at all. We could allow methods to have any names the programmer wants and in the result we will get ... Smalltalk. The need to formalize the class interface was one of the main reasons I started this project. Only time will tell if this approach is feasible but at the moment you may consider this as a basis assumption on which the language is built.

P.S. The discussed functionality will be implemented in the upcoming weekly release (probably in two week after 1.6.2 release). In the next post I will display how symbol subject can be used to implement bf interpreter.

ELENA 1.6.2 released

2011-06-26T05:38:00.000-07:00

ELENA 1.6.2 is out now

This release includes alpha version of ELENA script engine, changes in the language syntax, new library lib2(only console samples are migrated).

Starting from 1.6.2 the migration to a new library LIB2 began. At the moment all console and rosetta stone ones are migrated to LIB2

The work on GCX (a revised garbage collection) continues. Young and old generations are introduced.

ELENA Script Engine is introduced. At the moment it is very early alpha version.

Other changes

it is possible now to switch to another role inside another one
run-time multi-dispatching
new argument option: nullable
obsolete argument option: norecc
#continue is no longer supported
new statement: #try
some basic byte code optimization rules
new compiler options: g0, ox
some basic byte code optimization rules

ELENA Virtual Machine Script

2011-06-10T03:04:00.000-07:00

The last year in the article The Next Big Thing I mentioned the intention to create a special VM script to manipulate with the objects. It took me half a year to come up with the possible solution. And though it is a very early alpha a new tool introduced in the current release (bin\elt.exe) put this idea into practice.

So what is ELENA script? First of all it should not be confused with a traditional script language, it has not its own interpreter, grammar, libraries. It is pure a set of instruction for ELENA VM to load existing symbols into the memory and send them messages. So its prime goal is to assemble objects in VM memory with the help of special rules (if it is done from ELENA program it could be considered as a self assembling, hence its name - DSA (dynamic self assembling) rule). The possibility to work with your own objects directly without need to write a special test program could be useful as well. I hope it will find an application for code generations, open architecture systems (as a way to build complex group objects) and so on.

The actual system consists of VM terminal (elt.exe) and a special script engine (elenasm.dll) working with ELENA Virtual Machine (elenavm.dll). It is designed to be used directly from ELENA program as well (of course if the program is VM client). There are actually two types of script: inline one (which can be used directly with VM without need for the script engine) and grammar driven (where context-free and DSA rules modify the script text to create an inline one, so it could be considered as a additional layer between the client and VM).

Before I will show how it looks to work with VM terminal I would like to notice that at the moment it is very early alpha version and it is still unstable. Secondly direct script requires some knowledge of ELENA stack machine: a symbol reference should be always preceded by a parameter (if there is no parameter, nil constant should be used), the same is true for the message call. Thirdly only generic messages can be used (without a subject qualifier; actually it was designed for such a use from the beginning). Note also, that the current implementation allows to work only with console applications. There should be a special VM client for GUI applications. And finally it is presumed that you works with LIB2 programs (if you need to use LIB, please change libpath in elt.cfg to ..\lib)

So let's start the terminal. Inline script should be executed with an option "-i"

First of all we need to start a virtual machine and load default template

-i @config win32_vm_console2 @start

The canonical hello world sample will be looked like this:

-i &nil 'program'output "Hello World!!" ^write

Let's print the sum of two numbers:

-i &nil 'program'output 2 3 ^add ^write

Now let's do a bit more complex task and call existing application (it should be compiled before). First of all you have to tell VM where your compiled modules are located

-i @use "..\examples\binary"

And now let's execute the program symbol:

-i &nil binary'program &nil ^evaluate

As you see it is not very convenient way to write the expression (but it could be ok for computer programs). So let's try to use some grammar. I would like to note that the script engine support simple context free grammar. There are several restriction: only one terminal symbol (it should be first) and non-terminal (with except of AB type rule) can be used. So only the following type of rules are allowed:

S::=aA
S::=a
S::=A
S::=AB
S::=$eps

So let's define our simple rule

-g print ::= "?" expression;
-g expression ::= $literal;

(Note $literal is a special terminal mask accepting any literal constant)

DSA rules are used to provide required symbols and operations.

-g print => &nil 'program'output $body ^write;

(Note $body indicates the place where rule content is inserted)

Now let's mark print as a start rule

-g start ::= print

Let's test if our code works

? "hello world!!"

You could load existing scripts as well

-c..\examples\opencalc\opencalc.vl2

And now you may calculate some basic arithmetic expression

?2*3+4*5

You may look how your expression is translated into direct script with the following command -ton

-ton
?2*3+4*5

You will see the script listing. To turn the tracing off type the following

-toff

To exit the program, type

-q

That's all I would like to show in this tutorial. In near future I will show some more complex samples (for example I will implement bf interpreter)

P.S. Note that in the current implementation several key features are lacking, for example it is not possible to declare variables. I'm going to implement them in the recent releases. Once again it is still unclear if this turns into something more than a nice toy but it is the direction ELENA Program Language Project is moving to.

"Weekly" release 1.6.1.2

2011-06-10T03:03:00.000-07:00

This is a weekly service release.

optimization: direct method call for constants and external roles
new statement: #try
bsort migrated to lib2
fixed bug with inline class argument hint
vm terminal
script engine

You may download it from sourceforge - ELENA 1.6.1.2

LIB2: Tutorial, part 1

2011-05-28T04:38:00.000-07:00

As work continues on LIB2 more samples are moved to it. So it's time to take a look at the changes the new library brought with it

#symbol Program =>
[
   'program'Output << "Hello World!!%n".
 
   'program'input get.     // wait for any key 
].

As you can see little was changes: a generic message GET is used instead of CHAR'GET. So let's look at more complex sample: words

#define std'basic'*.
#define std'collections'*.
#define std'patterns'*.
#define ext'text'*.
#define ext'patterns'*.
#define ext'routines'*.

#subject std'dictionary'*.

#subject total_words, unique_words.

// --- WordList ---

#class WordList
{
    #field theList.
    #field theTotal.

    #method new
    [
        theList := List.
        theTotal := Integer::0.
    ]

    #method += aWord
    [
        theTotal += 1.
  
        #if (ListSearching::theList ==aWord)?
            | [ theList += aWord literal. ].
    ]

    #method total_words = theTotal.

    #method unique_words = theList count.

    #annex (theList).
}

// --- Program ---

#symbol Program =>
[
    'program'output << "Enter the text(to stop press enter two times):%n".

    #var aFlag := Boolean << True.
    #var aText := TextWriter.
    #var aWriter := #annex(aText)
    {
        << aLiteral
        [
            #if (aLiteral length == 0)?
            [
                aFlag << False.
            ]
            | [ aText << aLiteral. ].
        ]
    }.

    #loop aFlag?
    [    
        'program'Input >> aWriter.

        aWriter += " ".
    ].

    #var aList := WordList.

    WordScan::aText run: aWord => (aList += aWord).

    'program'output << "There are " << aList unique_words << " unique words out of " << aList total_words.
    'program'output << "%nthe list of unique words:%n".

    aList~CollectionPrinter save:'program'output.

    'program'input get. // wait for any key
].

The first thing that catch an eye is a possibility to use symbol names without a namespace qualifier or an alias. New modules (like ext'routines) and classes (ext'text'TextWriter) were introduced. ext'patterns'WordEnum was renamed to WordScan. An external role ext'routines'CollectionPrinter is used to print the collection. Qualified messages unique_words and total_words are used instead of private ones $getTotal and $getUnique. Apart from these the sample logic remains the same: with the help of wordscan the entered text is split into words and only unique words are saved in the collection; the resulting list is printed at the end.

"Weekly" release 1.6.1.1

2011-05-27T13:01:00.000-07:00

This is a weekly service release. It contains several major changes in ecodes(complete overhaul of ELENA bytecode opcodes, making this release incompatible with 1.6.1), some changes in group support, multiple dispatching. The migration to LIB2 continues, several samples were moved to it

it is possible now to switch to a role inside another one
new ecode: snop
run-time multi-dispatching
obsolete argument option: norecc
new argument option: nullable
intsum & realsum migrated to lib2
binary migrated to lib2
new compiler option - g0
ecodes are simplified, several big commands are split
#continue is no longer supported
words migrated to lib2
some basic byte code optimization rules
new option to turn on / off optimization - ox

You may download it from sourceforge - ELENA 1.6.1.1

The next several posts will discuss what's new in LIB2 comparing with the LIB

ELENA 1.6.1 released

2011-05-05T12:40:00.000-07:00

ELENA 1.6.1 is out now

This major release includes changes in the language syntax, several critical bug fixes and enhancements in the language library code.

1.6.1 is not binary compatible with the previous versions (due to changes in ecodes and a grammar)

multi-threading support

GCX (a revised garbage collection) is now thread-safe

changes in ecodes (ELENAVM byte codes)

several “big” commands are split, to reuse existing ecodes (disptach, redirect)
new ecode – popn

simplified syntax to create a group

instead of old style syntax

#group(events'EHandler, BtmSave) += …

it is possible to use the following syntax

BtmSave~events'EHandler += ..

#define command without an alias

it is possible to include another namespace without providing a namespace shortcut

#define std'basic'*.
…
Integer << 2.

new compiler hint syntax

instead of old style

#hint(subj:mysubject)
#class MyClass {…}

a new syntax is introduces

#class(subj:mysubject)MyClass {…}

#hint is no longer supported

the new hint syntax should be used

several major changes in an expression syntax

The following syntax

A verb:B::C

should be replaced with

A verb:(B::C)

An argument list could be used in initializing expression

A::&arg1:B &arg2:C

The following code do not need an extra brackets any more

#inline alias(A, B, C) verb:D

several bug fixes

a bug in memory management
a #group statement bug for x platform
cannot compile class with roles in the release mode bug
#00058: duplicate subjects
#00059: win32_gui_vm_client and win32_console_vm_client applications do not work
#00060: #var a := a verb:b circular referencing
upndown bug:player plays with a joker as a biggest one
bug: 64bit integer numbers are displayed incorrectly in the debugger watch window

lib2

the work on an alternative system library is began. LIB2 will replace existing one after 1.7.0
hellowworld_u sample migrated to lib2

IDE

IDE is now ready to debug multi-threading applications

Weekly release - 1.6.0.3

2011-04-22T13:24:00.000-07:00

After quite a long period of time I finally made a next release.

This time it includes several major changes in ELENA byte-codes and syntax.

- Several "big" bytecode commands (like redirect and dispatch) are split into smaller ones to reuse existing commands. It means 1.6.0.3 is not binary compatible with previous versions.

- It is possible now to include other symbol namespaces without aliases. I.e. instead of old code:

#define basic'* = std'basic'*.

...

  #var anObject := basic'True.

it is possible to write the following:

#define std'basic'*.

...

  #var anObject := True.

- The simplified syntax to create a group. Compare old code

           #group(events'EHandler, BtmOk) += 
            { on'Click'process = self set &dialog_result:basic'false.  }.

with a new one:

           BtmOk~events'EHandler += 
            { on'Click'process = self set &dialog_result:basic'false.  }.

- There is a simplified syntax for providing compiler hints:

#method(disp) += anObject
[
    ...
]

The work on an alternative library (lib2) is started. It will eventually replace the existing one starting from 1.7.0

Current status

2011-04-05T01:07:00.000-07:00

It has been a while since my last post and a last release. So I decided to post a little update on the project status.

At the moment I'm working on introducing a new concept to the language - external role (or ELENA protocol).

As you probably remember a role is an alternative VMT. But I realized that there could be an external one. It can be considered as a short-time mutation as well. The good thing is that unlike a normal mutation (either #annex or #group) it does not introduce any performance overload. As a result I will implement an alternative API (so called API2), located in lib2 (the source code in src2).

So how it will be used? For the programmer there will be nothing new. For example, we've implemented a protocol __address. To use it we have to write the following: anObject1 __address ifequal:anObject2.

anObject1 actually may not know anything about the protocol (though in most cases it should implement some methods to support the protocol).

The next release will contain the first implementation of the protocol concept

Weekly release - 1.6.0.2

2011-03-18T20:31:00.000-07:00

This is a weekly service release. It contains several major bug fixes.

- fixed #group statement bug for x platform
- fixed critical error: cannot compile class with roles in the release mode
- fixed gui'controls'Combobox-items append method doesn't work with a literal value

As a part of the compiler development (x project) the work on multi-threading support was continued. IDE is now fully ready for debugging several multi-thread applications;
new modules:sys'threading, win32'api'threading.

Rosseta code tutorials:Arithmetic evaluation

2011-03-04T03:00:00.001-08:00

Today, let's consider another rosetta code sample - Arithmetic evaluation

We have to evaluate an arithmetic expression by building the parsing tree. So let's define tree elements being used by the parser:

#subject parse_order.

// --- Token ---

#class Token
{
    #field theValue.
    
    #method parse_order'get = 0.
    
    #method += aChar
    [
        theValue += aChar.
    ]
    
    #method + aNode
    [
        ^ aNode += self.
    ]
    
    #method new
    [
        theValue := String.
    ]
    
    #method numeric = theValue save:Real64Convertor.
}

// --- Node ---

#class Node
{
    #field theLeft.
    #field theRight.
    
    #role Empty
    {
        #method += aNode
        [
            theLeft := aNode.
            
            $self $setLeftAssigned.
        ]
    }
    
    #role LeftAssigned
    {
        #method += aNode
        [
            theRight := aNode.
            
            #shift.
        ]
    }
    
    #method $setLeftAssigned
    [
        #shift LeftAssigned.
    ]

    #method + aNode
    [
        #if (self parse_order > aNode parse_order)?
        [
            self += aNode.
        ]
        | [
            aNode += self.
            
            ^ aNode.
        ].
    ]
        
    #method += aNode
    [
        #if (theRight parse_order > aNode parse_order)?
        [
            theRight += aNode.
        ]
        | [
            theRight := aNode += theRight.
        ].        
    ]
    
    #method new
    [
        #shift Empty.
    ]
}

// --- SummaryNode

#class SummaryNode (Node)
{
    #method parse_order'get = 2.
    
    #method numeric = theLeft numeric + theRight numeric.
}

// --- DifferenceNode ---

#class DifferenceNode (Node)
{
    #method parse_order'get = 2.
    
    #method numeric = theLeft numeric - theRight numeric.
}

// --- ProductNode ---

#class ProductNode (Node)
{
    #method parse_order'get = 1.
    
    #method numeric = theLeft numeric * theRight numeric.
}

// --- FractionNode ---

#class FractionNode (Node)
{
    #method parse_order'get = 1.
    
    #method numeric = theLeft numeric / theRight numeric.
}

Our tree will consist of Token instances (leaf nodes) and Node descendants (branch node). Any branch branch may have two children. So the expression 1+2+3 will be presented like this:

       --(+)----
      |         |
  -- (+)--     [3]
 |        |
[1]      [2]

To correctly parse the expression like 1+2*3 any node should return its precedence level (parsing order). That's why we declare a new property (actually new subject) - parse_order. The tree is evaluated by sending real'get message to the top node, which in turn sends it to its children until we reach terminal node (Token). Each brunch node (SummaryNode, DifferenceNode and so on) performs the associated operation with the results and at the end we've got the result of the expression.

Let's consider some parts of the code. Token's numeric'get method converts the literal value to a numeric one:

theValue save:Real64Convertor

Add message (operator +) is used to connect two nodes with each other in accordance with their precedence levels. To add children nodes to the brunch one append message (+= operator) should be used. Note the use of roles there. Instead of checking each time if the sub node was already attached we define two roles - Empty and LeftAssigned. Due to current implementation limitation we cannot switch from one role to another one inside the role so a private method is used ($setLeftAssigned).
To support precedence-control parentheses we have to declare a special node - SubExpression. It is actually a sub tree. Note, we have to use Parser class before its declaration. It can be done by providing the symbol namespace (if our module is named as arithmeval - arithmeval'Parser).

#class SubExpression
{
    #field theParser.
    #field theCounter.
    
    #role EOF
    {
        #method eof'is []
        
        #method += aChar [ $self fail. ]
    }
    
    #method parse_order'get = 0.
    
    #method + aNode
    [
        ^ aNode += self.
    ]
    
    #method append : aChar
    [
        #var aCode := Int32Value::aChar.

        #if control if:(aCode == 41)
        [
            theCounter -= 1.
        ]
        | if:(aCode == 40)
        [
            theCounter += 1.
        ].
        
        #if(theCounter == 0)?
            [ #shift EOF. ^ $self. ].
        
        theParser evaluate:aChar.
    ]
    
    #method numeric = theParser numeric.
    
    #method new
    [
        theParser := arithmeval'Parser.
        theCounter := Integer << 1.
    ]
}

The field theCounter is used to deal with nested parentheses.Now let's declare our parser class.

#class Parser
{
    #field theToken.
    #field theTopNode.
    
    #role Start
    {
        #method evaluate : aChar
        [
            #if (40 == aChar)?
            [
                theToken := SubExpression.
                theTopNode := theToken.
                
                $self $setBrackets.
            ]
            | [
                theToken := Token.
                theTopNode := theToken.
                
                theToken += aChar.
                
                #shift.
            ].
        ]
    }
    
    #role Brackets
    {
        #method evaluate : aChar
        [
            theToken += aChar.
            
            #if theToken eof'is
            [
                #shift.
            ].
        ]
    }
    
    #role Operator
    {
        #method evaluate : aChar
        [
            #if Control if:(48 < aChar) if:(58 > aChar)
            [
                theToken := (Token += aChar).
                
                theTopNode += theToken.
                
                #shift.
            ]
            | if:(40 == aChar)
            [
                theToken := SubExpression.
                theTopNode += theToken.
                
                #shift Brackets.
            ]
            | [ $self fail. ].
        ]
    }
    
    #method numeric = theTopNode numeric.
    
    #method evaluate : aChar
    [
        #if Control if:(48 < aChar) if:(58 > aChar)
        [
            theToken += aChar.
        ]
        | if:(42 == aChar)  // *
        [
            theTopNode := theTopNode + ProductNode.
            
            #shift Operator.
        ]
        | if:(47 == aChar)  // /
        [
            theTopNode := theTopNode + FractionNode.
            
            #shift Operator.
        ]
        | if:(43 == aChar)  // +
        [
            theTopNode := theTopNode + SummaryNode.
            
            #shift Operator.
        ]
        | if:(45 == aChar)  // -
        [
            theTopNode := theTopNode + DifferenceNode.
            
            #shift Operator.
        ]
        | if:(40 == aChar)
        [
            theToken := SubExpression.
            theTopNode := theToken.
            
            #shift Brackets.
        ]
        | [ $self fail. ].
    ]
    
    #method new
    [
        #shift Start.
    ]
    
    #method $setBrackets
    [
        #shift Brackets.
    ]
}

Parser is an action class used by a literal enumerator. Evaluate method is called for every expression character to build the parser tree. Once again the roles are used to deal with special cases (like parentheses).

Parser class gives us an opportunity to speak about conditional statements in ELENA. Because the language does not have any built-in types it is problematic to implement classical conditional statements. One possible solution is implemented in Smalltalk where closures are used (the similar could be done in ELENA as well). The second solution used by the language takes into account another ELENA feature - alternative flow: if the object does not react to the message (no appropriate record in VMT) the flow is considered to be broken and control goes to the alternative one. So the conditional statement in the language looks like this:

#if anObject message1:aParameter1 // first condition
[
   ....
]
| message2:aParameter2  // second condition (optional)
[ 
   ... 
]
|    // else condition (optional) 
[
   ...
].

Though conditional statement can be used with any message, operators ? (is) and ! (isnot) are used in ELENA API. It is presumed that a true value (std'basic'True symbol) reacts to ? operator and a false one (std'basic'False) to ! operator. So the conditional statement may look like this

#if aFlag?
[
   // true part
]
| ! [
   // false part
]
| [
    // error part
].

Comparison operators (==, !=, >, < and so on) returns either true or false values (or fails if the operands are not compatible). So we could write like this

#if (32 < aChar)?
[
   ...
].

Note that we compare an integer to the character rather than other way around - to convert character value to a numeric one.

If several conditions are required we could use 'and' and 'or' messages (supported by boolean symbols)

#if (48 < aChar) and:(58 > aChar)
[
].

Note, that in this case both condition are evaluated (unlike C++ for example). But it is still possible to achieve using std'patterns'Control symbol

#if Control if:(48 < aChar) if:(58 > aChar)
[
]

In this case if the first condition is not true the control goes immediately to the alternative part (if presented).

And finally, the conditional statement (as well as a loop one) does not break the flow if the message fails and there is no alternative statements (as opposed to a normal statement). That why we have to break it ourselves (if we want to inform the method caller that the operation is failed).

#if Control if:(48 < aChar) if:(58 > aChar)
[
   theToken += aChar.
]
...
| [
   $self fail.
].

It is presumed that fail message is never handled.

#symbol Program =>
[
    #var aText := String.
    
    #loop ((Console >> aText) length > 0)?
    [
        #var aParser := Parser.

        Console << "=" << aText then: aText =>
        [
            Scan::aText run:aParser.
            
            ^ aParser numeric.
        ]
        | << "Invalid Expression".
        
        Console << "%n".
    ].
].

The main program body is quite simple. We read the user input, parse it and prints the result (or an error message if the expression is invalid) until the user enters the empty line. ctrl'Control-then method evaluates the action (closure; a la Smalltalk) and returns the result.

Rosetta Code: Arrays

2011-02-28T05:20:00.000-08:00

Today, let's discuss the work with array (In this post I combined several tasks).
First, lets' show the basic array syntax
There are several ways how to declare the array in ELENA. The simplest way looks like this

#var anArray := (1, 2, 3).

Note that the array is an object containing the references to the integer objects rather than values itself. By default the array object inherits std'basic'Array class.
The syntax to retrieve the element is quite simple:

#var anItem := anArray@1.

Note that @ message returns the indexer proxy rather than the element itself. If you wish to retrieve the object itself the code should be a bit more complex:

#var anItem := (anArray@1) content.

To find out the difference between these variants let's examine the concept of an indexer. The indexer is a special adapter allowing to access the array members. To create indexer it is enough to send indexer message

#var anIndexer := anArray indexer.

The indexer can retrieve or assign the current array element with content'get / content'set methods (note that set method works only for dynamic arrays) and navigate the array (it is similar to the C array pointer). So to retrieve the element we have to create an array, move to the required position and return the content:

anArray indexer write &index:1.

But it is possible to use more simple way with the help of "refer" message (@ operand).

anArray @ 1.

Let's consider the following sample:

ctrl'It::anArray run : anItem =>
[
   'program'Output << anItem << "%n".
]

In this code we print every member of the array. Note that the object is extended with its index.

ctrl'It::anArray run : anItem =>
[
'program'Output << "a[" << anItem index << "]=" << anItem << "%n".
]

We could use an enumerator as well. In this case the object rather then the indexer is used:

ctrl'Scan::anArray run : anItem =>
[
   program'Output << anItem << "%n".
]

If we would like to get the original object from the proxy (for example if it should be assigned to the class field, in this case it is not optimal to store the proxy) we should use content'get message:

anArray@1 content.

Now let's see how could we create a dynamic array:

#var anArray := basic'NewArray::3.

In most cases there is no difference between the constant and the dynamic one except assigning the value:

anArray@0 set &content:2.

I hope it is clear now why we have to do it this way.After a dynamic array is created all its members are nil. Though it is possible to create and fill the array at the same time

anArray := factory'NewArray::{ &factory'array_size:3 &factory'pattern:(Integer::0) }.

And finally let's consider the code to calculate the mean(arithmetic average) of a numeric vector.

#define std'basic'*.
#define std'patterns'*.
#define std'dictionary'*.

// --- Sum ---

#class MeanAction
{
    #field theValue.
    #field theCount.
    
    #role Empty
    {
        #method numeric'get = 0.
        
        #method evaluate : aValue
        [
            theValue := Real::0.
            theCount := Integer::0.
            
            #shift.
            
            self evaluate:aValue.
        ]
    }
    
    #method new
    [
        #shift Empty.
    ]
    
    #method numeric'get = theValue / theCount.
    
    #method evaluate : aValue
    [
        theCount += 1.
        
        theValue += aValue.
    ]
    
    #method start : aPattern
    [
        aPattern run:self.
        
        ^ self numeric.
    ]
}

// --- Program ---

#symbol Program =>
[
    'program'Output << MeanAction start:Scan::(1, 2, 3, 4, 5, 6, 7, 8).
].

In short we execute the special action object for every member of the collection (or an array) and then print the result. The program code is quite simple (once again we use an enumeration, but this type with implicit action object instead of anonymous one), so let's look more precisely at MeanAction.Enumeration code pattern executes the action for every member of the collection by sending "evaluate" message (=> operator) with the collection member. So we have to declare this method and calculate the total sum simultaneously counting the numbers. "numeric'get" method returns the array mean. In the object constructor we initialize the action fields. Till this moment all is quite straightforward. But there is a special case - zero vector (an array with zero members). If we try to return the mean for it the program will crash with divide by zero exception. So we are creating a special set of methods (Empty role) to deal with it and switch the object to it (#shift Role). If evaluate method is called at least once than the vector is not zero and we have to use the standard set of methods (statement #shift).

Rosseta code tutorials:Amb operator

2011-02-25T08:01:00.000-08:00

Practically from the very start I had a problem with finding interesting samples to be implemented on ELENA. And only recently I found a place where I could find them

So I'm continuing implementing these tasks. My next sample is Amb operator.

Let's consider several tasks - one (with literals) from rosetta code (i.e. it is a failure if the last character of word 1 is not equal to the first character of word 2, and similarly with word 2 and word 3, as well as word 3 and word 4) and another (with numeric) from here. We will call them Program1 and Program2.

#symbol Program1 =>
[
    #var A := AmbValue::(1, 2, 3).
    #var B := AmbValue::(4, 5, 6).

    AmbOperator::(A, B) seek: => (A * B== 8).
    
    'program'Output << A << "*" << B << "=8".
].

#symbol Join =
{
    if &first:aFirst &second:aSecond
    [
        ^ aFirst@(aFirst length - 1) == aSecond@0.
    ]
}.

#symbol Joinable : aPair = Join if:ctrl'Args::aPair.

#symbol Program2 =>
[
    #var A := AmbValue::("the","that","a").
    #var B := AmbValue::("frog", "elephant", "thing").
    #var C := AmbValue::("walked", "treaded", "grows").
    #var D := AmbValue::("slowly", "quickly").

    AmbOperator::(A, B, C, D) seek:
       => (Joinable::(A,B) and:Joinable::(B,C) and:Joinable::(C,D)).
    
    'program'Output << A << " " << B << " " << C << " " << D.
].

How does Amb operator work? At first we have to define set of possible values for amb operator to choose from (AmbValue). Then we ask AmbOperator to find a correct subset. Joinable symbol is used for a tricky condition of the rosetta code sample (a@(a length)==b@0). ctrl'Args symbol is used to simplify the symbol argument list (i.e. Join if:ctrl'Args::(a, b) is similar to Join if:{ first'get = A. second'get = B. } or Join if:(&first:A &second:B)).

So let's consider the code to implement Amb operator.
We start with a multi-list enumerator. I would like to remind that an enumerator is used in ELENA to execute an action for every member of a collection (similar to foreach statement in C#). Why we need an enumerator? To find a correct solution AmbOperator has to go over all possible combinations of amb operands. So let's implement it (it is declared in ext'patterns module):

#class MultiEnumerator
{
  #field theEnumerators.

  #role BOF
  {
      #method proceed
      [
          #shift.
        
          ctrl'Control run &list:theEnumerators &foreach:anEnumerator => (anEnumerator proceed).
        
          ^ basic'True.
      ]
  }

  #method enumerator = $self.

  #method proceed
  [
      #var aRetVal := ctrl'Control run &list:theEnumerators &foreach:anEnumerator =>
      [
          #if(anEnumerator proceed)?
              [ ^ basic'False. ].
            
          anEnumerator clear proceed.
      ].
    
      ^ (basic'nilValue != aRetVal).
  ]

  #method new : aCollection
  [
      #shift BOF.
    
      theEnumerators := basic'ArrayType evaluate &__array &count:(aCollection count) &filling: aCurrent => (aCollection@(aCurrent indexer) enumerator).
  ]

  #method get = nil.
}

There is nothing special there. In the construct we create a list of enumerators for every member of the parameter. There is a special use case at the beginning (role BOF) where all enumerators are initialized (first call of proceed method). With each next call of proceed method the first enumeration goes on until it reaches the end, then it is repeated for the next member of the second enumeration and so on until the last enumeration is finished.

Now we need AmbValue enumerator:

#class AmbEnumerator
{
  #field theValues.

  #role BOF
  {
      #method proceed
      [
          theValues $reset.
        
          #shift.
        
          ^ basic'True.
      ]
  }

  #method new : Values
  [
      theValues := Values.
    
      #shift BOF.
  ]
 
  #method proceed
  [
      ^ theValues $next.
  ]

  #method clear
  [
      #shift BOF.
  ]

  #method get = theValues.
}

AmbEnumerator is actually an adapter which dynamically modify (mutate) AmbValue by calling private methods - $reset (AmbValue is wrapped around the first member of its collection) and $next (AmbValue is wrapped around the next one).

#class AmbValue
{
  #field theValues.
  #field theCurrent.

  #method enumerator = AmbEnumerator::self.

  #method $reset
  [
      theCurrent := theValues@0.
  ]

  #method $next
  [
      #var anIndexer := theCurrent indexer.
    
      anIndexer += 1.
    
      ^ anIndexer eof'is back:basic'False | back:basic'True.
  ]

  #method new : Values
  [
      theValues := Values.
      theCurrent := nil.
  ]

  #union (theCurrent primary).
}

As I said before AmbValue is a proxy class (dynamic extension) over the collection of possible values. Only one value at the time can be accessible (statement #union). "Primary" message is used to return the actual object (note that theCurrent is an indexer).

And finally our AmbOperator

#symbol AmbOperator : Values =
{
  seek : anExpression
  [
      ctrl'Control run &enumerator:exctrl'MultiEnumerator::Values &foreach: aCurrent =>
      [
          ^ anExpression evaluate inverted.
      ].
  ]
}.

So how does it work? The key is AmbValue. With a help of ELENA magic AmbValue could be wrapped around one of its members.

    #var A := AmbValue::(1, 2, 3).
  #var B := AmbValue::(4, 5, 6).

At the beginning A and B points to nil objects. But if we will call $reset method they will be equal to 1 and 4 integer constants (actually are wrapped around them, bit for other parts of the program they ARE integer numbers). After we call $next method they will be 2 and 4. Others are quite simple. AmbOperator with the help of MultiEnumerator executes the required expression for every possible combination of A and B values (i.e. 1 and 4, 1 and 5, 1 and 6, 2 and 4 and so on) until the expression is true (A * B = 8). Et voila!

P.S. The code works for ELENA API starting from 1.6.0.1 (I'm going to release it very soon). I added exctrl'MultiEnumerator and fixed several bugs in indexer implementation (without them the code for Join symbol should be like this: (aFirst literal)@(aFirst literal length - 1) == (aSecond literal)@0.).

Rosseta code tutorials:Add a variable to a class instance at run-time

2011-01-28T15:10:00.001-08:00

Another Rosetta code sample here

Though ELENA does not support adding a function / variable at a run time this could be simulated with the help of a group object (Note that ELENA does not allow a direct access to the object fields at all).

So we have to create a group member FieldContainer which will hold the variable and a pair of the methods to access it (get / set).

First of we have to declare a new subject (a property name) - foo

#subject foo.

Then a property container:

#class FieldContainer
{
#field theValue.

#method foo'set : anObject
[
theValue := anObject.
]

#method foo'get = theValue.
}

So now we could extends any existing object

// adding a field
anObject := #group(anObject, FieldContainer).

anObject set &foo:"bar".

#var aConstant := #group("My String", FieldContainer).
aConstant set &foo:"boo".

'program'Output << anObject foo.

Rosseta code tutorials:Ackermann function

2011-01-28T03:23:00.000-08:00

Let's implement Ackermann function - Rosettacode.
Because ELENA is a pure object-oriented language we have to create the object which will calculate the function. This object will only evaluates the parameter so we have to declare symbol with the single method "evaluate" (note that a new class can be declared both as implicit symbol - #class MyClass {} and as an explicit one -
#symbol MyClass = { ..}, the only difference that the symbol cannot have fields and be inherited).

#symbol Ackermann =
{
evaluate &m:anM &n:anN
[
#if (anM == 0)?
[ ^ anN + 1. ].

#if (anM > 0)?
[
#if (anN == 0)?
[ ^ self evaluate &m:(anM - 1) &n:1. ].

#if (anN > 0)?
[ ^ self evaluate &m:(anM - 1) &n:(self evaluate &m:anM &n:(anN - 1)). ].
].

self fail.
]
}.

The implementation is quite straight-forward but there are several things I would like to explain. Any ELENA method has only one parameter but it is still possible to pass several ones using the argument list (which is in fact the single object which returns the expected arguments). The argument names have to be declared beforehand
(see - Method calling syntax).
We may declare the new ones or reuse existing ones from std'dictionary'math module.

#subject std'dictionary'math'*.

Secondly Ackermann function is defined for n and m bigger or equal to zero. So we have to decide what to do if one of the parameters is negative. ELENA does not support exceptions so we have to break the program flow. It is done by sending the special non-existing message - fail - to itself.

self fail.

Now we could calculate our function:

'program'Output << Ackermann evaluate &n:1 &m:1.

Let's modify our code using the appropriate signature (note that << and write are synonyms):

'program'Output write &ackermann &m:0 &n:3.

To use this signature we have to declare a class with a "signature" hint:

#hint(signature:(ackermann, m, n))
#class AckermanValue
{
#hint(arg:m)
#field theM.

#hint(arg:n)
#field theN.

#method m'get = theM.

#method n'get = theN.

#method int'get
[
^ Ackermann evaluate:self.
]
}

Because a signature should be in the same module as the leading subject we introduce a new one - "ackermann":

#subject ackermann.

Note that declaring AckermanValue class we do not specify its type (ELENA is actually a type-less language but we could assign a subject to it which can be used as its "type " by multi-dispatching mechanism), so 'program'output will not know how to print it. We have to add a new method to implement a custom print action.

#class AckermanValue
{
...

#hint(disp)
#method save : aWriter
[
aWriter << self int.
]

#method __textwriter'save : aWriter
[
aWriter << "A(" << theM << "," << theN << ")=" << self int.
]
}

Let's examine these methods. It is presumed that a generic "write" method calls back its parameter. So we have to implement a new method "save". The problem is that actually any writer could call this method. Therefore there should be some conditional statement to check if the parameter is a text writer (subject - __textwriter). It could be achieved with the help of multi-dispatching by marking a generic "save" method with "dispatchable" (or "disp") hint. Now if a parameter is a text writer, "textwriter'save" method will be called instead.

The expression output will be the following:

A(0,3)=4

ELENA 1.6.0 released

2011-01-27T08:32:00.000-08:00

This release includes major language changes (method calling overhaul, simplified message argument list syntax, new classes and several critical bug fixes) as well as refactored ELENA standard library.

A new concept of method signature is introduces (reusing code, simplifying the message
sending syntax). In general the number of subjects was reduced. For example the subject content is no longer supported. The generic verbs are now used to set / get indexer / variable content.
1.5.6:

anArray@3 content'set:anObject

1.6.0:

anArray@3 indexer set:anObject

The subject bool was removed as well. Compare:
1.5.6:

#if (anInteger >= -2147483646)bool'or:(anInteger <= 2147483647)?

1.6.0:

#if (anInteger >= -2147483646)or:(anInteger <= 2147483647)?

I will post several tutorials describing 1.6.x features.

http://sourceforge.net/projects/elenalang/files/ELENA/1.6.0/ELENA-1.6.0.zip/download

ELENA Programming Language:method calling syntax

2011-01-15T05:48:00.000-08:00

In this post I would like to make a short overview of ELENA method syntax features (starting from 1.5.6.9 version).

ELENA programming language (unlike many others) introduces several limitation on the programmer free will over naming and using methods. First of all the method can have only one parameter. Secondly there are special rules how the method could be named (apart from private ones, which we will ignore in this post).

The simplest method declaration may look like this (in case of in-line class, the keyword is omitted):

#method subject'verb : parameter
[
]

As you see the method name consists of two parts: a subject (a noun) and a verb. The verb defines an expected operation, the subject describes a method parameter (a list of possible operations with it).
If the message do not have a subject part it is considered to be generic (and can be used for multi-dispatching). The 'GET' messages may omit their verbs. The following expressions are equivalent: “aNumber int'get” and “aNumber int” (“int” is a subject).

There are a limited list of verbs in ELENA (though this lists will be expanded with the time, to avoid possible verb overuse). Let's name them: add, and, append, back, check, clear, clone, close, delete, dispatch, divide, do, equal, evaluate, find, free, get, greater, if, ifequal, ifless, ifnot, increase, insert, is, isnot, less, load, multiply, new, not, notequal, notgreater, notless, open, or, proceed, process, react, read, reduce, repeat, rewind, run, save, send, separate, set, start, stop, subtract, wait, write, xor.

There are synonyms (operators) for some verbs. Unlike normal verbs, operators have lower parsing order. These codes are equivalent - “a << b + c int'get” and “a write:(b add:(c int'get))”. Operatiors are generic verbs and cannot have subjects. Let's name the operators and their verbs:
== - equal,
!= - notequal,
>= - notlesss,
<= - notgreater,
> - greater,
< - less,
? - is,
! - isnot,
@ - seek,
=> - evaluate,
>> - read,
<< - write,
+ - add,
- - subtract,
* - multiply,
/ - divide,
+= - append,
-= - reduce,
*= - increase,
/= - separate

Unlike verbs the subject names are not limited (it is not recommended to give a name equal to a verb, because of possible ambiguity). But the subject should be declared before the use. The syntax looks like this:
#subject subject, argument1, argument2.

It is possible to import subjects declared in another packages (the subjects declared in the project are automatically imported in all following modules).

#subject math'dictionary'*.

If there is a name conflicts between subjects declared in different modules it is possible to provide an alias (will be implemented in 1.6.0).

#subject math'* = math'dictionary'*.

It is possible to import the subjects to the whole project (std'dictionary, std'dictionary'protocols, std'dictionary'types subjects are imported automatically to any program or library).

Though the method may have only one parameter it is still possible to provide several arguments with the help of argument objects. Let's consider how we could declare the method with an argument list.

#method subject'verb &argument1:anArgument1 &argument2:anArgument2
[
]

This code will be compiled into the following:

#method subject'verb  : anArguments
[
 #var anArgument1 := anArguments argument1'get.
 #var anArgument2 := anArguments argument2'get.
]

The similar syntax could be used for passing multiple arguments to the method (note that it doesn't matter if the method declaration uses an argument list).

anObject subject'verb &argument1:anArg1 &argument2:anArg2.

This code will be compiled into the following:

anObject subject'verb: { argument1'get = anArg1. argument2'get = anArg2 }.

As it was already said above the subject defines the method parameter. This feature is used in ELENA for implementing multi-dispatching.

Let's declare three classes A, B, C and assigns subject1 to the class A, subject2 to the class B (class C does not have assigned subject).

#hint(subj:subject1)
#class A
{
}

#hint(subj:subject2)
#class B
{
}

#class  C
{
}

Now we will declare the fourth class which will deal with them.

#class D
{
 #method subject1'set : anObject [ … ]

 #method subject2'set : anObject [ … ]

 #method set : anObject [ … ]
}

We are going to call the verb set with instances of classes A, B and C. According to our notation for the instance of the class A we have to call subject1set, for an instance of B – subject2'set. Because the class C does not have an subject we should call generic method set (it is expected that the generic methods are able to work with “unknown” objects). So lets declare three variables and call the appropriate methods.

#var anA := A.
#var aB := B.
#var aC := C.

D subject1'set:anA subject2'set:aB set:aC.

But in most cases we do not know its type (in ELENA its class or supported subject). It is possible dynamically resolve the appropriate message. Let's add a special attribute to the generic method.

 #hint(disp)
 #method set : anObject [ … ]

Now we could simplify the code and the appropriate message will be called automatically

D set:anA set:aB set:aC.

And finally let's consider the concept of an argument signature. A signature allows to define the message subject on the base of argument list (static multi-dispatching).

Let's presume we have a following argument list

#method subject'set &argument1:anArg1 &argument2:anArg2 &argument3:anArg3 […]

Instead of passing every time all three arguments we could define three alternative argument signature: &argument1 & argument2, &argument2 & argument3 and &argument1 & argument3.

#hint(subj:subject, signature:(argument1, argment2), signature:(argument2, argment3), signature:(argument1, argment3))
#class CustomArgumentList
{
 #hint(arg:argument1)
 #field theArg1.

 #hint(arg:argument2)
 #field theArg2.

 #hint(arg:argument3)
 #field theArg3.

 #method argument1'get = theArg1 nil'isnot | back:0.

 #method argument2'get = theArg2 nil'isnot | back:0.

 #method argument3'get = theArg3 nil'isnot | back:0.
}

(Note that the signature class, should be declared in the same module where the first argument is declared). The mapping between argument value and a signature class field is defined by arg hint.

So now we could use simplified syntax to call subject'set

anObject set &argument1:anArg1 &argument2:anArg2.
anObject set &argument2:anArg2 &argument3:anArg3.
anObject set &argument1:anArg1 &argument3:anArg3.

Note that the order of the argument subjects play important role. &argument2 &argument1 and argument1 &argument2 are different signatures.

If the argument list contains only one argument it will be automatically translated into an appropriate message.

anObject argument1'set:aParam and anObject set &argument1:aParam are equivalent.

The signature cannot be used in the method declaration. If no appropriate signature can be found the generic method will be called.

Weekly release: 1.5.6.9

2011-01-14T12:11:00.000-08:00

1.5.6.9 is a snapshot of the work on upcoming major 1.6.0 release. Part of the code was not yet ported to the new platform. Nevertheless it includes all major improvement designed for 1.6.0.

The main change of the coming release is an improved argument syntax. Let's compare -
1.5.6.4:

'program'Output << 
      translit'Transliteration::translit'RusLat run:aSource << "%n%n".

1.5.6.9:

'program'Output write &_cyril2lat &literal:aSource << "%n%n".

“&_cyril2lat &literal:aSource” - is called argument signature and allows to reuse the code.
For example we could use the same signature in another method without any change in basic'String code –

basic'String append &_cyril2lat &literal:aSource

In the next posts I will discuss it in details

Up'N'Down 0.1 is released

2010-12-24T12:49:00.001-08:00

After more then two years I managed to release the first version of Up'N'Down game, the first "real" program written with ELENA.

http://sourceforge.net/projects/upndown/files/0.1/upndown-bin-0.1.zip/download

Weekly release: 1.5.6.4

2010-12-20T04:19:00.000-08:00

There were several critical bug fixes (disabled debug mode crashes executable file, cirtical fix in $next keyword implementing, cirtical fix in the long integer constant implementation), a new class std'collections'dictionary and some minor changes in the language itself.

First, I'm continuing to re-factor ELENA API code. As you probably know the language features some formal rules regarding the method names. They consist of subject and verb. The number of verbs are limited and should be well-defined. As it appeared there is a two ambiguous verbs - do and run. So starting from 1.5.6.3 the code review is proceeding and as a result some of subjects were dropped (like literalinfo, memoryinfo and so on). The main goal is to make sure that the subject defines the method parameter (with exception for 'do' verb) rather then the operation. Another goal is to make sure that the subjects are reusable (which is not the case for the subject like literalinfo).

Second bug change deals with operators. The operators are normal methods with custom parsing order. The expression '2 + 3 * a int' is parsed like 2 + (3 * (a int)).
Because of they nature it was not possible to provide the operator with the subject.
As a result the use of operators was limited. Starting from 1.5.6.4 the operators are synonyms to 'normal' verbs:
'==' <=> 'equal'
'!=' <=> 'notequal
'+' <=> add
'?' <=> is

and so on.

ELENA Programming Language: The Next Big Thing

2010-12-09T04:36:00.000-08:00

I've started the project more than 10 years ago. I've made a decision to create my one language in the summer of 1999. I had a quite vague idea what it would be except the idea that it will be a pure object-oriented language with late binding (dynamic one). So at first I was occupied with technical tasks implementing the compiler. The syntax was not important (due to a LALR parser which gave me total freedom over it). Compiler-free linker was created and since that I was able to concentrate on the language itself. ELENA is a frame language actually, it doesn't implement the "real" code (like adding numbers, comparing strings and so on). So I was free from this as well and concentrated on experiments with different language models (still in object-oriented frames). In 2006 I published the project on the sourceforge site and since that the work was accelerated. In 2007 the modern-like syntax was introduced. In 1.2.0 (2008) the first dynamic features were introduced (context-dependant roles). In 1.2.5 the dynamic inheritance was introduced. The latest version 1.5.6 introduced the final version of method calling routine (subjects and verbs). So what will be a next big thing?

Starting from 1.5.7 I will start so-called "y project". It's main goal is to create a special meta language which will be a high level abstraction script for the language virtual machine (elenavm). Unlike "traditional" scripts it will be not imperative. In ideal case it should be set of instructions how to assemble (self-assemble) the set of objects (symbols in ELENA terms) which will be able to solve the problem (objects themselves are written in normal way). The test bed will be opencalc sample. With the help of vmconsole the programmer will be able to interact with the system by entering the script (actually recombining existing ones).

One could say, is it real or just a pipe dream? At the current moment it is hard to say. It is actually a manifest or declaration of intent. The direction I'm going to work on. But I hope the first result (probably very early) will be already seen in the 1.5.7 release. Time will say

Weekly release: 1.5.6.3

2010-12-04T16:18:00.000-08:00

What's new since 1.5.6.1:

1.5.6.2

- changed inline class implementation
- new symbol ext'io'TextReading
- fixed std'basic'memory:bugs with memory operations
- fixed critical bug with long number constant
- new project template - guivm
- new : std'patterns'Validation symbol
- new : sys'groups'StaticBroadCaster
- dynamic symbol loading
- new symbol sys'vm'loader

1.5.6.3
- drop support of streamable subject
- fixed matrix sample
- enum verb is obsolete, use run
- indexerloop symbol is obsolete - use index
- loop subject is obsolete
- new verb:rewind
- control-evaluate should be used intead of control-run
- control-run / control-rewind repeats the action while the result is true / false
- canvas: possible to select color and font

It is now possible to load dynamically symbols by their name (for vm clients)

Starting with 1.5.6.3 the work on ELENA API refactoring is started. The main focus would be methods named like xx'run and xx'do. At the moment there are too many such names.

As I wrote before ELENA introduces an original concept of method naming. Unlike many other languages the language proposes a formal rule for method naming. The normal method name consists of the subject and the verb. As it appeared there are too many methods with subject which in fact a gerund rather then a noun. So I will rename such methods to make the subjects more resusable. And some form of subject morphology is introduced: [subject]+ing <=>[subject] + for + action (e.g. range and ranging, list and listing).

So bsort sample is changed:
1.5.6.2:
- ctrl'IndexerLoop backwardloop'run &from:aLastIndex &till:0 &for:anArray &action:
1.5.6.3 (a new verb rewind):
- ctrl'IndexIterator ranging'rewind &for:anArray &till:aLastIndex &action

1.5.6.2:
- ctrl'IndexEnum loop'run &for:anArray &action:
1.5.6.3:
- ctrl'IndexEnum listing'run &for:anArray &action:

The subject loop is obsolete ( it is in fact a process rather then an object )

Weekly release: 1.5.6.1

2010-11-08T09:23:00.001-08:00

I spent the last week fixing number of bugs, including several critical ones:
- fixed the issue with the focus in upndown sample
- fixed int64 division
- fixed int64 subtraction
- add possibility to import subjects on the level of the module
- critical bug with nested conditional statements
- critical bug with GC

Most of the work was done with upndown sample which is now more stable. I plan to release the first alpha version of the game during the current month

x-project reached a significant milestone: young generation garbage collection routine is tested for console applications, next will be gui ones. After that I will start to implement multi-threading routine

ELENA 1.5.6 released

2010-10-29T01:36:00.000-07:00

What's new in 1.5.6

Despite my promise in the previous post I released a new version early and it is a major one. Once again the method calling routine was overhauled.
So what's the point of it? After the subject concept was introduced the number of subjects increased at very high speed. Practically any new functionality brought new subjects as well. So I realized that proposed solution is not ideal and there is a question of subject reusing. So the next step was to start to use it for different patterns. But this contradicted with the original goal of subjects - to prevent possible name conflicts. As a result I separated generic subjects from domain oriented. Instead of "aControl control'items" I use "aControl control items" (where items is a generic subject and control is a part of gui dictionary). Thus the code was simplified (both compiler and source ones) and several ideas were dropped (property, nested subjects and so on).
Another very important change deals with nil'ifnot. Actually "if" or "ifnot" verbs require a parameter. "is" does not need is. So Instead of "nil'ifnot" - "nil'if" is used (and this is more logical than the previous message, only nil symbol should support it)
And of course all these changes broke the compatibility with the previous versions (but I hope this will not require any significant efforts).

Here the comparison between 1.5.5.x and 1.5.6 code samples:

aControls @ connector'SecondPlayerID control'items control'selected'index'set:0.
aControls @ connector'SecondPlayerID items selected'set:0.

#var aPlayerInfo := aControl control'items control'selected control'tag.
#var aPlayerInfo := aControl items selected tag.

#if aValue nil'ifNot [self write:aValue. ].
#if aValue nil'is | [self write:aValue. ].

1.5.5.11 weekly release

2010-10-21T15:58:00.000-07:00

1.5.5.11 release is out now.

There are several enhancement over method calling: it is now possible to use nested secondary subjects, #property keyword is introduced (yet not fully tested).

Several major bugs were fixed, including
#00057 (read a long string from the console) and a one with 64bit integer constants.

Small changes in ELENA API: ctrl'IndexBackwarding is no longer supported, a new symbols - std'patterns'Loop, std'patterns'IndexLoop, std'patterns'IndexBackLoop and std'patterns'IndexerLoop should be used

Work on linux migration and x-project is continued

A major release is sheduled on mid of novermber ( actually it will be one of normal weekly release ).

1.5.5.10 weekly release

2010-10-12T13:34:00.000-07:00

ELENA 1.5.5.10 is out.

The release features a new control - gui'controls'Menu ( look at notepad sample to learn how to use it ).

Several new methods were added:
- std'collections'List
* clear - clears the list;
- win32'controls'edit / win32'controls'memo
* edit'selection'get - returns the edit cursor position and the selection length
* edit'selection'set - sets the edit cursor position and the selection length

For example
#var aPosition := theEdit edit'selection edit'selection'starting. // the cursor position
#var aSelection := theEdit edit'selection edit'selection'length. // the selection length or 0 if the text is not selected.

A #00056 bug is fixed: when the default encoding is unicode there were problems with ansi files

ELENA Project code is moved to gcc4 (it took me some time before I was able to compile the code, I even started to think over moving to MSVS Express)

Method Calling tutorial

2010-10-04T06:36:00.000-07:00

From the first programming languages procedures (or functions) play very important role. Introduction of object-oriented paradigm increase this role even more. So it is not possible to program a language without learning the way how it handles procedures. This tutorial will show that this is not so trivial in ELENA.

When ELENA programming language was designed I made an important decision - to limit the number of method parameters to just one (concept of the limited object interface). It was done to make the object interface (or protocol if you wish) as much polymorphic as possible (selecting one set of parameters over others implies the way how it will be used; anyone who tried to add another method with the same name in the C++ base class knows that it could be a painful process).

So how String.Insert(index, value) method could be implemented if you cannot provide another parameter? There are general several ways how to do this. First way would be to introduce a special class (in this case std'basic'LiteralIndexer) which will be a mediator (agent) between string and the piece of code where the substring is inserted. So in ELENA it will look like this anStr@index insert:value ( @ operator will return an indexer pointing to specified position). One good thing with this that it is a code pattern. So every time we would like to insert something into an indexable collection we will use this way. But sometimes we have to set several peer parameters (like x and y coordinates). Of course we could set them independently but if it is important to set them simultaneously the second way could be used - aControl location'set: { location'x = 20. location'y = 20. }. The good thing is that location'set is a polymorphic method ( no change in the method interface have to be made if we decided to use three-dimensional or polar coordinates). The bad thing that the expression is quite big. So a special simplified version could be used - aControl location'set &x:20 &y:20. If the method requires no parameters a special nil symbol is passed to it - aControl control'open ( <=> aControl control'open:nil).

Being dynamic ELENA does not allow to implement a method overload a la C++. Instead the polymorphic nature of method parameter can be used. For example std'patterns'IndexEnum::pattern'run could use two set of parameters - ctrl'IndexEnum &for:anArray &action: => [ .. ] and ctrl'IndexEnum &from:anArray@2 &action: => [ ... ]. std'basic' LiteralIndexer :: literalinfo'create method is another example. If we would like to copy a substring from the specific position till the end we could omit parameter at all - aStr@2 literalinfo'create. If we wish to provide a substring length - aStr@2 literalinfo'create &length:10. If we are interested in copying a substring from one indexer till another - aStr@0 literalinfo'create &till:(aStr@1 literal'seek:" ").

Note that in all examples above a single method body was used. If we need a specific implementation for different parameters multi-dispatching routine should be used. In ELENA multi-dispatching is similar to traditional polymorphism with the only difference that executing code depends on a parameter rather than the object. For example if the method parameter is an integer - an integer operation should be executed. If it is a real number - real one and so on. e.g. - aWriter write:2 write:2.3r write:"literal" should correctly write to the stream an integer, a real and a literal values.

How could we achieve this on the language with the late binding (no compiler magic like in static languages)? Several ways could be used. One of them would be to ask the parameter to do the operation itself (after all who knows how to handle the object better than the object itself?). The problem with these approach (which is used in ELENA as well) that the object should know all possible operation with it. In ELENA a method naming limitation makes the things even worse (It is not possible to call the method copyToInteger, lessThenInteger as it would be discussed later). So as an alternative the concept of the subject was introduced.

The subject could be considered as a declarative type (a unique token). For example std'basic'Literal, std'basic'String and gui'control'Edit are all implement literal subject (note that they do not share common code with each other except a generic super class). The subject should be declared before use. It is inherited but the class may support only one subject (it is done with a special compiler hint - #hint[subj:literal] before a class or symbol declaration).

Before continuing let's consider another topic where a subject is used - method naming. As opposed to many main stream languages ELENA limits the way how a method can be named. Any public message may consist of subject and verb (generic messages have only verb part of the name). The number of verbs are limited and well defined (e.g. and, get, set, read, write, start, run and so on). The subject is defined by the user and could represent an actor or type (bool'and, int'add, literal'read, indexer'get; see above). The subject may represent the process as well (pattern'run, process'start and so on).

So let's return to multi-dispatching mechanism. If our class (stream writer for example) handles a particular subject (integer, real or literal values) the method name should contain the appropriate subject (int'write, real'write and literal'write). This approach allows the object to notify any potential user of expecting parameter type (note that in a language with late binding like ELENA the mismatch type errors can be found only in run-time) or returning value (literal'get) or expected operation - (process'stop). As a plus this helps us with multi-dispatching as well. If we mark our class as dispatchable (#hint[dispatchable]) when the expression aWriter write:2 write:2.3r write:"literal" will actually invoke int'write, real'write and literal'write respectively.

1.5.5.9 weekly release

2010-10-02T17:06:00.000-07:00

After a false start, ELENA 1.5.5.9 is out.

This release contain a new sample notepad which uses a new class gui'common'LayoutManager designed to auto adjust control location when the form is resized.

on'resize event is now raised after the control size is changed.

The work on linux migration and x project continued

1.5.5.8 weekly release

2010-09-25T11:05:00.000-07:00

A new weekly version is out now.

After a long delay it is now possible to debug elena vm clients. IDE Project settings were changed. There are three debug modes: disabled, enabled and enabled in vm. To debug vm client the third option should be selected.

The work on upndown, dtcalculator and eldoc samples continues.

I finally fixed the problem with helloworld sample (#00053) (it is shame that it took so many time to find out that I forgot to change the method name from 'do' to 'evaluate').

New symbols: sys'dates'today (theoretically it should return only date without time), ext'patterns'printingln (will print the line and moves the cursor to the new line).

I modified textfile reader implementation. The reader no longer returns trailing %r%n characters.

New methods:
std'patterns'indexenum search'run &from
(e.g ctrl'indexenum search'run &from:a@3 &value:b
- compare with ctrl'indexenum search'run &for:a &value:b)

sts'basic'literalindexer literalinfo'create &till
(e.g a@i literalinfo'create &till:a@j
- compare with a@i literalinfo'create &length:(j - i))

ELENA Programming Language: Object model

2010-09-20T06:02:00.000-07:00

ELENA is a general-purpose, object-oriented, polymorphic language with late binding. It features multiple dispatching, context-dependent roles, dynamic inheritance and group object support.

The language treats any program as a set of objects (class instances). The program flow is a process of interaction between objects by sending each other messages. A message may have attached information (a message parameter). An object may react on message if it has an appropriate message handler (a method). If the object reacts on the message it is treated as successful otherwise unsuccessful. In its turn the method may send messages to other objects and so on until the flow reaches the method written by external tools (meta method). If the message is unsuccessful the flow is considered to be broken. It's possible to declare alternative flow which are executed if previous ones are broken. The method has only one input parameter and one output parameter (if the method returns itself it may be considered as an input one).
Every object may be formed up with other objects characterizing its internal state. They in turn may be formed with others and so on until meta objects which internal states are considered as raw data.
All referring entities in the language are objects. A variable is a reference to the object allocated in the program heap. The literal and numeric constants are references to the objects allocated in the static memory.

Any object is an instance of one or another class. The classes form the hierarchy tree on the principle of inheritance. There is the common super class - Object. The class parent may be explicitly declared. When the parent is not specified, the class inherits Object.

A class is an abstract concept which means that no operations can be done with it except a declaration. So to create the object its symbol should be referenced. There are explicit and implicit, static and dynamic symbols.
When a new class is declared simultaneously the appropriate implicit symbol is declared as well. The explicit symbol should be declared explicitly. In general the implicit symbol is the object in the initial state and the explicit one is the object in the particular state.
A static symbol is the class instance which state is preserved. A static symbol is always explicit one. There could be only one instance of static symbol.
The class declaration can be named or unnamed (inline declaration) public or private (when the class name is a private name). Its body contains member declarations: fields, roles and methods.

The fields can be accessed only within the class and its descendants. They can be a normal ones (references to another objects) or meta ones (raw data).
The roles are alternative sets of methods which could be used to implement context-dependent object behavior. When it is applied the role overrides the appropriate object methods with its own ones (static mutation).

Methods maybe private or public depending on their name (public or private). All class methods are considered to be polymorphic. It is possible to dispatch the method call depending on its parameter (declarative multi-dispatching). The method has only one input (or nil) and output (or it should return itself) parameters. If the method requires several parameters a special proxy argument list object can be used.

It is possible to declare a special "Any" handler. It is a method which redirects any unhandled message (i.e. messages which are not mapped in the class or its base classes) to the specified target. The target could be a single object (actually mutation) or collection (group object). A group object is a collection of the objects accessible through the common instance reference. The content of the group can be changed dynamically during the object life time (self-modification). The member objects can be a part of different groups or be single. The group can be persistent or temporally created to solve the particular task. The group objects are treated like "normal" ones and no special routines are required to work with them. If two or more members have duplicate methods either the first message mapping is resolved (exclusive mode) or all duplicate methods are executed (broadcast mode) depending on the group type.

1.5,5,7 weekly release

2010-09-19T04:29:00.000-07:00

Several new symbols were added to ELENA API:
sys'io: BinaryFile, NewBinaryFile
ext'text: HexAdapter, EIntFormatter, ELiteralFormatter

BinaryFile and NewBinaryFile are adapters to work with binary files.

#var reader := BinaryFile::"file.dat" reader'get.
#var writer := NewBinaryFile::"newfile.dat" writer'get.

Returned reader and writer support basic reader / writer protocol to work with data.

HexAdapter will allow to convert hexadecimal literal constant to the integer and back:
#var S := ext'text'HexAdapter literal'of:2Dh. // -> "2D"
#var N := ext'text'HexAdapter int'of:S. // -> 2D

The work on upndown example continues. It is now possible to play basic rounds (without joker).

New binary corex.bin will contain an enhanced GC implementation supporting multi-threading.

Some settings were moved from elc.cfg to the specific templates (like console.cfg)

On the next week I will start a debugger redesign (to support elenavm client debugging), continue slow migration to Linux and a lot of other things.

I'm planning to start my first real open architecture application - opencalc.

So that's all for this week

ELENA Programming Language: Paradigm

2010-09-07T05:25:00.000-07:00

As a general purpose programming language ELENA is able to support various programming paradigms. But there is a special one the language was made for: open architecture paradigm (OA).
OA paradigm presumes that the system consists of the number of relative simple objects actively interacting with each other and forming object groups. The content of the group can be modified (self-modified) depending on its state or functionality. Typical group consists of several members representing different implementation layers. Let's presumes that we develop the card game. The main system actors will be: a game master, a player and a representer. We could define several layers: basic, game logic and multiplayer ones. A basic layer will implement the common functionality which will be used in any game. A game logic layer will care about implementing the game rules and a multiplayer one will support a chosen transport protocol. Additional layers can be applied to any game actors, like AI one for the player. Testing environment can also modify the system to set up some test scenario and so on. A group content will be modified to be more suitable for the current game stage (for example a computer player may change it content for implementing different strategies, if the game has different stages the game master will be self-modified to lead the appropriate game stage). At the game start the main groups will be self-assembled depending on the user choice.
In general OA paradigm tends to change the accent from a vertical inheritance to a horizontal one. It will make the program implementation more decentralized, limiting the number of "super" objects. The main advantage of this approach is the possibility to extend / modify system more easily, sometimes even without need to recompile it.

1.5,5,4 weekly release

2010-09-03T11:21:00.000-07:00

A new version is available - 1.5.5.4

It contains mostly ELENA API bug fixes and a new symbol - gui'dialogs'errorbox

Method calling in ELENA: overhaul, part 2

2010-09-02T02:35:00.000-07:00

First of all, I would like to announce changes in the project release practice. Now there will be two types of releases: official and weekly ones. Official release will happens once per several months (version number x.x.x) as it was before. But additionally every several week I will publish weekly release (version numbers x.x.x.x) and they will be located in http://sourceforge.net/projects/elenalang/files/ELENA/Weekly.

The first such weekly release happened yesterday - http://sourceforge.net/projects/elenalang/files/ELENA/Weekly/elena-1.5.5.3.zip/download
The main purpose of that release was publishing the changes in method call syntax. Apart from this I did several small enhancements. First of all I decided to get rid of message subject prefix "gui". Though it is still possible to use it in most cases now it is recommended to omit it. So the old style code like this - self set &gui'location'x:50 &y:50 set &gui'size'width:700 &height:520 gui'control'caption'set:"Caption" - will look a bit better -

self location'set &x:50 &y:50 size'set &width:700 &height:520 control'caption'set: "Caption".

The same for event handler - on'control'Click'do has to be converted to on'Click'do.

Here the list of changes:

LiteralType and ArrayType "create" methods are now obsolete. LiteralType literalinfo'create &length and ArrayType arrayinfo &count should be used instead. If you wish to initialize the array during its creation you should use the same method - basic'ArrayType arrayinfo'create &count:10 &action: => (basic'Integer <<0)
ctrl'IndexEnum run &enum'in &action and ctrl'Enum run &enum'in &action are no longer supported - ctrl'IndexEnum pattern'run&for &action and ctrl'Enum pattern'run&for &action should be used instead.
gui'control'items'get => control'items'get
Event handlers "on'control'Paint'do" and " control'IndexChanged'do " should be converted into - on'Paint &canvas and on'IndecChanged &index
ext'patterns'ArrayType is no longer supported. Use std'basic'ArrayType instead
ext'io'textfile and ext'io' LogTextFile are no longer supported. They were moved into sys package. So use sys'io'textfile and sys'io' LogTextFile
std'patterns'Loop is refactored. Repeater pattern'run &for &action should be used instead

The old style syntax will be kept until 1.5.6 release. If you have any questions or problems with converting feel free to ask.

Method calling in ELENA: overhaul

2010-08-20T02:07:00.000-07:00

As I already told several times ELENA is developed in "evolutional" mode (which is quite suitable for an open source project where there are no major releases and new versions are released often). It has its pros and cons but it is fun because you never know what will be next (except the pain from rewriting the whole code again and again).

When I introduced a new syntax for sending messages in 1.5.5 I had no idea that already in 1.5.6 it will be overhauled once again (though this time I will try hard to keep backward compatibility).

Before I will outline what will be new in 1.5.6 I will shortly describe the history of the problem.

I told this hundred times but it's worth repeating it again. ELENA is a highly dynamic language. This means that many approaches which are suitable and easy in the world of static languages may be problematic in the dynamic one. One of them is sending messages. You may ask what problem may be with calling a method? Yes, in a statically typed language it is not a problem (though with typecasting you may shoot your feet easily) but in a dynamic one there is a chance that message meaning was overloaded (after all human languages are very ambiguous). You send "or" message supposing the bit wise operation while a receptor treats it like Boolean one. So you either check the object type or pray that this time it will be ok. In ELENA it is even worse. A group object may consist of several objects many of them were not designed to work with each other so the chance of name conflict are quite high. After trying several other techniques I proposed the concept of a message namespace (though it was designed for other purpose).

In 1.5.5 this concept gets final implementation (I hoped so but the time proved that I was wrong). Every message consists of a subject and a verb. The number of verbs are limited (like in many human languages) and well defined (in a theory, in reality it is more or less defined :)). The subject have to be defined in the program and usually belongs to the program use case. For example "or" is a verb. "Int" and "bool" are subjects (representing integer and Boolean values). So if you need bitwise "or" - "int'or" should be used, otherwise "bool'or".

It appeared that the concept of subjects may be used not only for calling methods but for implementing multi-dispatching as well. std'basic'Integer and std'basic'LongInteger may support "int" subject, std'basic'Boolean, std'basic'True and std'basic'False support "bool" one. So if the receptor is dispatchable (it means the object support mutli-dispatching) the operation - receptor or:parameter - will produce different results depending on the parameter subject (in contrast to polymorphism where the result depends on the receptor type). If a parameter is an integer number - "int'or" will be executed. If a parameter is a boolean value - "bool'or". And so on.

Moreover I found that the subject may help me with another problem. ELENA is a language with a limited operational set. It means that the object method may have only one parameter. Actually it is not a big problem. If you need to pass several parameters you may use something like this - control location'set: gui'common'Point { location'x'get = 0. location'x'get = 0} (where x and y are second level subjects). But the resulting code is quite clumsy. So with the help of the subject I was able to simplify it (though keeping original concept) - control set &location'x:0 &y:0.
This approach made me happy until I started to migrate the code. It appeared that as a result I was forced to have two set of methods to support both of these expressions. And finally in 1.5.6 I found the way how to avoid it.

So the new version of the code will look like this - control location'set &x:0 &y:0. Not a big difference you may say. In fact it is. This could will be translated by the compiler to the following one - control location'set:#hint[subj:location]{ location'x'get = 0. location'y'get = 0. }. Which is equivalent to the original one. So no need to duplicate. And "location'set" method may look like this - #method location'set &x:anX &y:anY [ ... ]. This method will be able to support both type of passing multiple parameters and multi-dispatching one as well - control set:point .
Moreover I found that (once again :)) it may resolve another problem. Every time inline object was used the compiler create an appropriate VMT. As a result the code contains several duplicate VMTs. To resolve this some complex logic should be involved. Subject will fix this problem. Every time a subject with secondary items are declared the compiler will create a VMT. So no need to create them in place.

No one can stop me from continuing :). If a subject is declared with VMT I may customize get method. So it may help to reuse some common patterns. E.g. in location'set I have to call int'get for x and y every time I used them (don't forget a parameter may be a group or proxy object). Instead of this I will be able to write something like this - #xsubject location ( x => x int'get, y => y int'get ) (#xsubject will be used instead of #subject for backward compatibility with 1.5.5).

And finally (at least at the moment) I decided to simplify another thing. If you wish to return an object field you usually use the get method with secondary subject - point location'x'get. From 1.5.6 it will be possible to ommit get (and set) verb - point location'x (a subject cannot have a name coinciding with verb).

If you ask me what will be in 1.5.7? I will honestly answer - no idea :)

ELENA 1.5.5 released

2010-08-02T16:38:00.000-07:00

I would like to inform about a new release of ELENA Programming Language.

It took me almost 3 months to finish the work (I actually refactored ELENA library code twice). The changes are everywhere and unfortunately it means that the 1.5.5 is not compatible with 1.5.4 (now I do understand some software firms which do not like to support previous versions :)).

Just short overview of the changes:

1) hints:
Instead of old style compiler hints - #class[...] Edit (Control) - the special keyword has to be used #hint[...] #class Edit (Control)

2) messages:
several messages (actually message verbs) like proceed, continue, ifnotnil are no longer supported, the new ones are evaluate, do, nil'ifnot

3)Multiple dispatching mechanism is refactored and optimized. I will discuss this later in more details.

4) A new type of group object is introduced - #union. I will discuss this later in more details.

5) elena byte codes (ecodes) are redesigned, I continue to optimize the virtual machine command set

6) context'get is no more supported, use instead enum'content'get (for enumerations) or indexer'content'get (for indexers)

7) special type of messages is introduced to simplify passing the multiple parameters to the method (It took me so many years to invent the wheel but I'm quite happy with this implementation).

So instead of - theEdit gui'size'set:gui'Size{ gui'size'Width'get = 200. gui'size'Height'get = 24. } more simplified version could be used - theEdit set &gui'size'width:200 &height:24. I will discuss this later in more details.

Here the link - http://sourceforge.net/projects/elenalang/files/ELENA/1.5.5/elena-1.5.5.zip/download

Group Objects Example

2010-07-25T10:27:00.000-07:00

Let's consider the use of group objects.

In the next example I will demonstrate how to extend and customize code using branch-free self modifying code.
(Note that 'project' should be replaced with a name of the source file)

// --- namespace shortcuts ---
#define basic'* = std'basic'*.
#define ctrl'* = std'patterns'*.
#define list'* = std'collections'*.

#symbol Printing = anItem =>
[
// prints a parameter
'program'output << eshownext =" anItem">
[
// replace itself with ESkipNext
#inline elena'172 (self, $self, project'ESkipNext).
].

#symbol ESkipNext = anItem =>
[
// redirects the call to the next group item
$next proceed:anItem.

// replace itself with EShowNext
#inline elena'172 (self, $self, EShowNext).
].

#symbol Program =>
[
#var aList := list'List.
aList += 1 += 2 += 3 += 4 += 5 += 6.

// extending
'program'output << "All items:%n".
#group(ctrl'EEnum, aList) run:Printing.

// customizing
'program'output << "Every second item (1,3,...):%n".
#group(ctrl'EEnum, aList) run:#group(ESkipNext, Printing).

'program'output << "Every second item (2,4,...):%n".
#group(ctrl'EEnum, aList) run:#group(EShowNext, Printing).
].

The program start in Program symbol. Firstly we have to create a collection.

#var aList := list'List.
aList += 1 += 2 += 3 += 4.

In the code below we will enumerate every member of the collection and print it.

// extending
'program'output << "All items:%n".
#group(ctrl'EEnum, aList) run:Printing.

aList is extended with ctrl'EEnum adapter. EEnum is a FOR EACH pattern, executing the action for every member of the collection it is combined with. Printing is a simple action which prints a provided parameter. In combination this code prints every member of the collection.

Let's consider how could we customize it to print only every second item without if statement.

// customizing
'program'output << "Every second item (1,3,...):%n".
#group(ctrl'EEnum, aList) run:#group(ESkipNext, Printing).

Printing action is combined with a special adapter ESkipNext. ESkipNect redirects the flow to the next group item and modify the group by replacing itself with EShowNext. So during the next call EShowNext will be executed. EShowNext in its turn replaces itself with ESkipNext and so on. As a result we will print every second item of the collection. A voila.

To be continued...

Group Objects

2010-07-22T13:34:00.000-07:00

Let us define a group object as a collection of the objects accessible through the common instance reference. The member objects may or may not have any relations with each other. They may or may not have intersecting message mapping. The content of the group can be changed dynamically during the object life time (self-modification). The member objects can be a part of different groups or be single. They may not even notice they become a part of the group (dynamic overriding). The group can be persistent or temporally created to solve the particular task. In general the group objects are treated like "normal" ones and no special routines are required to work with them. If two or more members have duplicate methods either the first message mapping is resolved (exclusive mode) or all duplicate methods are executed (broadcast mode) depending on the group type.
So how may group objects be used? Let us consider several possible use cases: code customization, "branching-free" / self-modifying algorithms and horizontal inheritance.

Customizing / Extending existing code

The concept of the group object may be used for modifying the existing code. Sometimes only minor changes should be applied to the code to be reused. Commonly we may override the class. Or we could combine it with the special adapter class containing only the methods we would like to change (actually dynamically override it, see horizontal inheritance). Though this two patterns are quite equivalent, the group can be formed with any object implementing a particular protocol at a run time. And in contrast to an aggregation we have to implement only the methods we would like to change without affecting others (which is quite important for the dynamic language where we do not always know the object type). Moreover in some cases we will not need to write a new code at all, only combining well-defined components. In general it allows us to inject the code into the complex system without big modifications and this injection may be invisible for other parts of it.

"Branching-free" algorithms

The content of the object group may be changed during its life time and it gives us quite an interesting feature: every time the group internal state is changed its actual content may be changed as well. Though the total number of the different states is quite big we can always select several extreme ones (empty list, unassigned reference, read-only collection and so on), place the code related to them into a separate control object (or several ones) and combine it with the main code. So when the group state is changed the control object replaces itself with the appropriate one instead of checking the state every time (alternatively the control object may have a several set of VMTs). Self modifying group can be used as well in many cycle algorithms where the first or the last action are different from the main ones. The real "branch free" code is unlikely to be feasible but the moderate usage can still simplify the code.

Horizontal inheritance

Group object can be used as an alternative to a multiple inheritance as well. Common satellite classes can be included in different groups allowing them to share the code without actually inheriting it, helping us to reduce the depth of inheritance tree.

Having looked at several use cases let us examine the possible implementation of the group object concept.

Possible implementation

Being born as a part of the dynamic language study the group object definitely requires a pure polymorphic language with a late binding. For implementation simplicity the concept of limited object interface was introduced. We presume that any class method may have only one input and one output parameters. If the method does not require any parameter a special void parameter is passed (e.g. nil constant). If the method does not require to return anything it returns itself (e.g. self variable). As a result we have a system with relatively big number of "simple" classes actively interacting with each other to resolve any task (so we can say that the number of inter-class calls tends to be higher than the number of inner-class ones). Finally let us introduce a proxy handler concept. The proxy handler is a special kind of a method which is executed every time there is no message mapping in the class VMT. It may redirect the call to the specific target.
Summering all above any group object consists of the array of group members and a VMT containing only a special proxy handler. Depending on the type of the group it redirects the call to the first object handling the appropriate message (exclusive mode) or to all members (broadcast mode). Every time a member method is called the reference to the group is passed to it rather than to the object itself. So when the method calls another object method it is in fact redirected to the group (dynamic overriding).
The only problem with this approach (except performance of course) is an access to the object fields. To solve it we need to keep the reference to the object as well. In a standalone mode both variables refer to the object. In fact having two object references allows the programmer to decide whether the method call might be overridden or not.

Name conflicts

But how predictable could such groups be? After all we combine the objects which are not always well known to us. Will there be any message conflict leading to unexpected results? To ease this problem we may introduce the concept of the message namespace. The words in a human language are quite ambiguous and as a result the message names may be ambiguous too. "AND" could be bitwise or Boolean operation, "GET" may return any value and so on. So let us introduce a special language entity of a message scope which describes well-defined term (e.g. "integer", "boolean") and list possible operations with it (e.g. "get", "and" ,...). Any message used by the group member should belong to one or another message scope (which has to exist physically). As a result the chance that the different members of the group will use occasionally similar messages is quite small.

Critical review

Though the scheme above seem a bit complex it costs not so much: an extra check per message call and an additional object variable (if we compare it with the cost of transition from a static call to a dynamic one). But in any case we are facing a bigger concern - redundancy. It is easy to show that most of the possible features could be implemented without groups (after all any high level programming language is translated to the machine codes and by definition cannot be more powerful than the assembler).

So is the introduction of the new entity really justified? And though there is no simple answer to this question several reasons can be mentioned. First of all it promotes more polymorphic and extendable code. The possibility to customize the object behavior without actually knowing much about it (except supporting protocols) will give a programmer more flexible way to deal with existing / reusable code. Secondly this approach reshapes the system structure. Instead of multifunctional classes we will get plenty of rather simple ones with limited functionality which can be easily tested and reused. And finally combining them into super entities makes the system more open and configurable.
To summarize this type of redundancy may be a key factor how to build and maintain more powerful and complex systems with an open architecture. And though it is too early to say if the concept of the group object makes the difference it can give a boost to active use of more structural self-modifying collaborative code.

General language overview

2010-07-21T13:47:00.000-07:00

In the next several posts I will try to describe the language general overview, proposed programming paradigm and basic code patterns. So let's begin.

ELENA is an object-oriented programming language with the late binding. It means that it belongs to the same class as Smalltalk rather than C# or Java. It is a non-mainstream language and is used as a testbed for experiments with the language design, dynamic and self-modifying code and so on. So don't expect it will be easy to learn. Probably someone may say it is weird but I like its dynamic nature. It has weak sides but it DOES work. And finally it is a live language in the process of developing.

Let's consider several major language features which I will discuss in more details later.

ELENA is a language with the reduced class interfaces. It assumes that there is only limited way to interact with the object on the base of protocols supported by it. Any class method should perform an atomic operation, be quite small and support only one parameter. Moreover the strong concept of reduced class interfaces limits the possible operations between classes (belonging to different modules) to the small list of well-defined messages - verbs (though it is possible to provide "subject" for each verb, i.e. with "get" verb we can use several distinct messages: int'get or game'player'get). The method cannot have more than one parameter. As a result the method parameter tends to become an active partner. The method has to ask the parameter to return the required information, so the method caller has some control of the method work (in combination with dynamic mutation we could have some kind of two-way interaction).

ELENA is a language with a reduced operational set. Practically the only supported operation is sending a message to the object with a parameter. Conditional (#if) statement extends this operation with possibility to use multi-statement blocks and loop (#loop) one just repeats it until it fails. The only way to control the flow is message chaining. An ELENA program code is a sequence of actions (sending a message) enclosed in square brackets (Unlike Smalltalk the sub code is a sequence of action as well). The execution of every next action happens only if the previous one was successful. Otherwise the control goes to the closest alternative action and the flow continues. Alternative message chains are used in ELENA not only for handling exceptional situation but (and mostly for) conditional branching. The program code could explicitly break the execution (by sending fail message) to indicate the negative result of the method.

ELENA is a dynamic language supporting different run-time code manipulations. One of them is a static mutation. It is presumed that an object may have several alternative sets of VMTs (roles) and switch between them depending on its state. Though the total number of these states can be big enough we could always select several extreme ones (such as an empty string, unassigned container). Such cases could be implemented as class roles containing the code which is applicable only in the particular state. Only in the place where it could be changed (copying the value, assigning the object) we will check the situation and switch between roles. In most cases the bulk of the code would not be affected so there could be only several quite simple roles. But in some situation the whole code is divided between roles. E.g. Boolean variable could have two (or three) roles: true, false values (and undefined one).

ELENA supports a dynamic mutation as well. It means that we can dynamically override any public object method. This mutation could be either stable or temporal (if it is included into the temporal object group) and be accessible both inside and outside the mutated object (though inside the object we can explicitly decide if we allow overriding). It is possible either extends the object with some custom code or combine it with the number of other objects (so called object satellites) into a group object (will be described in the next post).

Concept of the group objects is one of the most interesting ELENA feature and I will continue to investigate it hoping that it will help to create self-modifying systems with truly open architecture (that in my opinion may lead to creating a very complex highly adaptive autonomous programs).

Yet another programming language

2010-07-21T13:41:00.000-07:00

Probably every person hearing about a new language asks this question: why yet another programming language? I cannot say about all but me. When I decided 10 years ago to create a new programming language I had several reasons. First of all it was a perfect way to learn C++ (as many Russians I came from Pascal & Delphi world). But most of all I was interested in object-oriented programming. For me it was a perfect chance to learn more about it. I was fascinated with Smalltalk and decided to do something similar. Writing the compiler is a quite challenging task but it cannot be compared with the task of creating a language or a programming paradigm (after all the most valuable things in our world are ideas). So after several attempts to invent / create something original I decided to follow other way: implement something simple and gradually modify it in hope to find something interesting. So step by step the language grew (practically any part of the compiler / language was rewritten / refactored at least several times) and now it has nothing common with the one I decided at the beginning. And though many of its ideas which I thought were original are used in other languages ELENA has its own individuality and style.

So how could I answer on this question? Is ELENA yet another programming language. The answer is not simple. Yes, ELENA may be considered as another amateur language with small source code base and lack of bug tracking functionality. And no, ELENA is a conceptual language. It is designed to examine / prove feasibility of several basic concepts. From the beginning I tried to make the language as dynamic as possible. My ultimate goal is to create the programming systems with truly open architecture, the systems which can be modified / extended in run time, the system where a big number of "simple" objects actively cooperate with each other forming group objects, able to self-modify. Will the language become something more than experimental one? Only time will show. Honestly I have no idea where the language will be in the next several years. One thing I may say definitely - it will be different.

In this blog I will try to show my current ideas and the state where the language is.