Warming up ISA
Iteration 4: ll basics and syntax
First of all, in this warm up, it is not yet time to define ll, the Last Language, in its whole completeness and rigor.
It is only the time to write some basic orientations and syntactic elements that will be an experience in building ISA itself.
Major guidelines
ll must be as simpler as possible and therefore readable. Contrary to Uncle Bob's directive, I think it must be close of current human languages, so basically relying on English and on mathematical signs.
To be simple, it should only allow one instruction per line of code. This means in particular in method calls, that only variables, properties or true values should be allowed, not complex expressions. It is compiler responsibility to eventually optimize local variable suppression and to perform inlining.
| I know and agree that Domain Specific Language (DSL) is good and efficient. And a programming language is some kind of DSL for the computing business domain. OK, but if it can be close to natural language and not verbose that's even better isn't it? |
ll is object Oriented, except when this drives to performance problem or when oo has proven to be weak: This means that in ll all oo axioms are respected.
One single language to express everything: LL.
So as meta-classes are also Objects, a class is expressed thru the serialized version of class. A class is defined by an Initializer. The Initializer instantiates an object from a serialized version of it. An Initializer is not a constructor; it is a transformer from an object representation to another.
A textual language, because this have proven to be the more efficient, but it is also proven that is is not sufficient. Graphical capabilities derived from textual expression should be also supported, in a similar way PlantUML do that. This cumulates the advantages of textual and graphical formats.
LL will just rely on usual punctuation and tabulations, and, on the other hand, prohibit any escape characters. It doesn't need any keyword. This allows extending or even completely redefining LL. This is why DSL, O.S. commands and scripting languages are not useful, because LL allows to express them natively in LL. For instance, the O.S. commands are just use cases exposed by the O.S.
| Having indentation to be significant could be criticized by the fact that bugs are not visual. Of course it could come from a clumsy space. But, please, using any decent editor allows to easily detect visually that kind of problem (Notepad++ for instance). At contrary, significant indentation make the code more uniform, less verbose and much more visual. In other words: it is easier to understand.
Literal Strings and Texts are always put into variables (rvalue), therefore detect them is easy. To distinguish end of line in code, and within literal line jump, it is simply established that in LL end of line is: CR + LF, while in literal expressions it is: LF + CR. |
LL must have a very large scope, from the specification to the execution. LL is seamless: This is the way to make it flexible to any processes.
LL is also its own meta-model.
LL is a dynamic language, but only by addition or removal of well-structured class (both static and dynamic). It therefore supports real multiple inheritance (and peer inheritance).
| Peer inheritance is the ability to inherit dynamically several time of the same class. For instance, an Individual may be Member of several Organization, this means inherit several time of the same Class, here Member.
This also promotes the separation between the most usual verbs: Be and Have. Being something is preferably represented by inheritance. Having something suits better with relationship. |
The wide usage of inference at compile type in type and argument mapping determination (type, name, position, multiplicity) also restrains needs for LL for dynamic behaviors, while improving usability, performance and safety. It is not only easiest for client code, it also increase the reusability and reduce verbosity.
LL follows the query / command separation principle.
LL supports the invariant, pre-condition and post-conditions notions because this make the programs much more secure.
Null is not supported, a not valued item is therefore optional and ignored at runtime like in Objective C. The Multiplicity and the Applicability are supported instead (they are ways to express invariants, pre-conditions and post-conditions).
Contrary of most languages, in LL the root object must be the richest as possible in order for all objects share as many features as possible. It is at this level in particular that LL incorporates basically the major oo Design Patterns and features like serialization.
Contrary to UML, relationships between model elements are not defined at the most general model element level. This drives to a multiplication of relationships and of constraints. The model relationships are just put at the right level with the right precise semantic.
Provide a very coherent set of basic Type hierarchy.
Basics types are mutable because 1/ this improves efficiency and 2/ concurrence issues are addressed by the implementation by ISA of oo paradigm (in particular the 1 thread per object approach).
Supports the characteristics associated to the identity axiom. Therefore, the notion of ID must be introduced. IDs are of 3 kinds:
- Memory address: In this case, the ID is no other than the object reference in memory.
- oid (Object ID): The identity when the Object is (typically) not in memory but can be pointed unambiguously. This supposes that at least the Nature of the Object is determinable.
- ID (simple ID): A general ID not necessarily pointing an Object (ID of version, business ID, semantic ID, etc.).