Lambda the Ultimate

Daikon

Daikon is an implementation of dynamic detection of likely invariants; that is, the Daikon invariant detector reports likely program invariants. An invariant is a property that holds at a certain point or points in a program; these are often seen in assert statements, documentation, and formal specifications. Invariants can be useful in program understanding and a host of other applications. Examples include “.field > abs(y)”; “y = 2*x+3”; “array a is sorted”; “for all list objects lst, lst.next.prev = lst”; “for all treenode objects n, n.left.value < n.right.value”; “p != null => p.content in myArray”; and many more. You can extend Daikon to add new properties (see Enhancing Daikon output).

Dynamic invariant detection runs a program, observes the values that the program computes, and then reports properties that were true over the observed executions.

Daikon can detect properties in C, C++, Java, Perl, and IOA programs; in spreadsheet files; and in other data sources. (Dynamic invariant detection is a machine learning technique that can be applied to arbitrary data.) It is easy to extend Daikon to other applications; as one example, an interface exists to the Java PathFinder model checker.

I spend a lot of time here talking about static typing, but let's face it: most often we're dealing with existing code that probably isn't written in a language with a very expressive type system, and rarely has been formally specified, whether through an expressive type system or otherwise. Daikon is interesting because it attempts to learn important properties of a piece of software by execution and observation. Combine it with a model checker like Java PathFinder, and you have an unusually powerful means of evolving the correctness of even quite complex code. There's also a relationship to the already-mentioned JML and ESC/Java 2, which in turn has a connection to the popular JUnit unit-testing framework. In short, the gap between compile time and runtime, and static vs. dynamic typing, seems to be narrowed in powerful ways by these, and related, tools.

I would like to discuss with you my ideas on new programming language for embedded applications, denoted further as e#.

Here I post only the core concept, more details can be found on this link

e# is a tool language that should be suitable for all kind of embedded-related development activities, starting from defining the device architecture and its instruction set, documenting device specifics and finishing with programming the device with a developed application. Instead of allowing the developer to write an arbitrary language constructions and pushing the compiler to made an executable out of it, e# should let a developer (a device vendor) to express the device resources, capabilities and constraints in the language terms. These capabilities and constraints than are applied to the application sources, simulation model and executable image. If any of the constraints are violated the e# builder would produce error, either compilation, simulation or code generation time.
It should retain major assembler’s capability to express application’s logic in terms of processors instructions, where each statement is translated into known number of know instruction of a given CPU/MCU.
The language should allow writing generic libraries for a given architecture operating on common architecture-wide facilities expressed in terms of a lowest subset of ‘abstract device instructions’ declared for the architecture, which then, at application level, are implemented/instantiated for a given MCU.
Shortly e# can be defined as a compilable code generator – at first sources are compiled then they are executed and, as a result of this execution, application code is generated. Compilation should not generate any target device code, it should only verify syntax and generate instructions on how to generate target device code. e# definitely is a high level programming language, however, applications written in it should still be able to use features of a low-level programming language, such as access to all available device resources.
It is believed that the concept could be applicable to RISC, CISC and VLIW architectures, although, the latter one will require more efforts on describing the device.