RSL2 was (is) a fully object-oriented dynamic language for developing server-based systems.
I wrote RSL version 2 in late 1996 / early 1997 on Linux and Solaris, from scratch after rearchitecting its original 1995 implementation. RSL2 is a C++ framework on top of which is a dynamic, fully object oriented language, designed for applications to take advantage of the power of C++ and the flexibility of a dynamic language for primarily web-based applications. Although "RSL" is the name of the system itself, I refer to the dynamic language also as RSL.
One of the unique properties of this system is that individual objects span the language boundary; a String or an Account object is the same object from the RSL layer as the C++ layer. One perspective this allows is the "atoms" of the system can be implemented in a low-level, efficient language like C++ and their interdependencies / relationships could be implemented at the dynamic, loose and free level of RSL. So in a typical UML object diagram showing the classes (boxes) and associations (lines among them) the boxes could be both C++ and RSL, but the associations can be entirely in RSL allowing them to be easily changed. This removes the vice grip the C++ compiler has on the system design, allowing it to be expressed in terms of objects and messages in a dynamic way. It doesn't make sense to me to do "high level" OO design but only be allowed to manipulate the objects with bit twiddling tools.
So... when I say RSL is "fully object-oriented" and "dynamic", I mean that like smalltalk, it is a system rather than a source-level language; everything in the system is an object; objects are treated as independent entities who communicate through messages (as opposed to the invocation of functions on an implicit object). From a programmer's perspective, this is alot about typing and polymorphism; everything is an object including language features, statements, scope, message definitions, parameter list definitions, and so on. RSL's rules about types and objects and messages are dynamic in that one can't determine from the source code what the type of an object is, because it is what it is no matter what the compiler (or programmer) thinks - so casting as in C/C++/Java doesn't make sense. See this document comparing C++/Java/RSL with the downcasting problem. Argument type checking in messages to objects is all determined dynamically - for better and for worse (see note about RSL's interesting parameter matching abilities below). Its syntax is loosely based on C++ and Java.
I enjoyed writing an object-oriented language and framework. I would like to do it again some day, a better way. I learned a lot about languages. In no way do I think RSL would be a replacement for Java, or C++; it's more like a way of thinking to how we should architect dynamic language systems in the future and represents a philosophy of programming on my part. I believe in the value and power of specialized languages, and I believe it is a problem that they can't work together to build, er- grow, a system. I'd like to see a language for searching, one for sorting, one for looping, one for math, one for text processing, one for each of the various kinds of financial systems, one for software architecture, one for programming language implementation (with which to write some of the others), etc., etc., and furthermore, they need to work within a common abstract framework. In object-oriented terms, concepts expressed in such abstract programming languages need to manipulate objects (ie send messages to objects) that are common among all the languages in a dynamic (live) sense; they should not generate code. When we express ourselves in programming languages, we should be speaking to the live system we're growing, not one that will be "generated" and must be brought up and brought down. APIs and text file source code will be antique.
but the problem is the corporate environment. It must be done within a product company with lots of money which is focused on developing the product. Or it must be done by individuals with lots of time to devote to it. Destiny, at the time, was a small consulting company trying to become a product company with neither the funding nor the focus to make it happen. I think it is amazing I got as much done as I did, but were I a product manager type, I may have been able to get more support by being more evangelistic about the value of what we had and what it meant. But I wasn't. App servers went horizontal, we were focused on the financial services vertical, we didn't completely know what we had, Java was on its way in, etc. End of story... or not! Want the code?
Classes and Objects:
Message interpretation / method selection:
When an object receives a message, it must select a method with which it will respond. This can be complex. As is typical with object-oriented languages of the C/C++/Java ancestry, parameter matching by type is done, albeit dynamically. In addition, parameters may be distinguished by name and by value giving a lot of programming flexibility.
by name
similar to SmallTalk and Objective-C, arguments may be sent with names: the expression object . m ( a: 3 ) sends message m with one actual parameter named a. object will understand this message only if it has a method m with a formal parameter named a. This makes the code much more readable, and allows methods to be distinguished by the role of the parameters (ie their names) rather than simply their declared types. an interesting side effect is that it allows parameters to be given in the source code in any order, provided they are named. Classes may also declare that they understand a message with named parameters given but no type.
by value
Formal parameters can be declared as requiring a specific value, eg
class X {
m ( A : Integer { 3 } ) { implementation }
}
declares that instances of the class X understand a message "m" which has an Integer called "A" with the value 3. Such value declarations could be of arbitrary complexity (for a price!) Some interesting recursion can be written in this way, moving a boundary decision out of the code and into the method selection algorithm. for example: (pseudocode)
f(int i) {
println(i);
f( i - 1);
}
f(int i: 0) {
println("done!");
}
Provided you invoke f() with a value greater than 0, this would stop when i is 0 because the second version of f() is invoked when the argument is precisely 0. In RSL this is approximately the same complexity as when done in the traditional manner, but much more flexible and much easier to read.
Interesting language features:
foreach x in (collection) { }
RSL's full polymorphism allows one to get around the iterator/enumerator stuff. collection can be any collection whatsoever, containing objects of any class.
logfile & tracing
Because RSL is an application server framework, it includes logging. Detailed tracing can be turned on for language features, recording things like which decisions were made by if statements, the values of parameters in messages, the number of times a loop was executed, etc.
Limited exception handling
Instead of try/catch blocks as in C++/Java, RSL implemented a special return-value checking. If an object of the class Status was returned to object X, a message is routed to X. X may be expecting such a message and provide a handler for various kinds of Status objects (switching on the values of Status object fields, for example - one could provide a handler for Status objects of a certain severity or code).
Connectivity (ECI- external client interface)
RSL, being dynamic, is just as much a system/framework as a language. It was oriented toward server construction, and therefore supported an object streaming technology, text-based. Any object in the system could be sent an arbitrary message, and receive a response. At this level, objects can return multiple values in response. There are no specific language features to deal with multiple return values, though it was on the board for implementation in the third version.
Session support
RSL was implemented as the framework for an application server, so it has built-in support for sessions. This means that an RSL process has a separate object space for each session which do not overlap. ECI messages must be directed at an object within one session space.