Friday, August 20, 2010

Method calling in ELENA: overhaul

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 :)

Monday, August 2, 2010

ELENA 1.5.5 released

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 -