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.