EDL
It's been three months since the last post, so I think I should write an update. The Eek language spec is mostly done, even though I still do some minor changes from time to time. Most of them remove restrictions from the language, for example my last change was to allow generic types in delegate signatures. They are the result of the evolution of Eek's intermediate language, EDL. My original idea of EDL was to have something like Java Bytecode, just in EXML. Instead of having a list of binary-encoded commands, I would have a list of elements that describe the commands. The next step was to use the tree-like structure of EXML and make it more like an AST rather than a list of commands. Thus the arguments of a command are children of the command element, and the children arguments are commands themselves. I still wanted have special commands for build-in types like integers, like Java does. Then I discovered that EXML is ideal for annotating the commands in the tree, which makes type inference relatively easy to do (among other optimizations). That shifted my goals somewhat, and I focussed on making EDL simple to parse and process. This also meant getting rid of all special cases, and the end result is a completely dynamically typed language that uses 13 different commands in a tree structure. Making EDL dynamically-typed may look odd, considering that I am a proponent of statically typed programming and Eek is probably even more statically typed than Java, but I believe that with a good compiler the resulting code will be not slower than the code of a typical compiler of statically typed code. The price is that EDL's design makes it more difficult to write a compiler with a performance that it comparable to a typical, 'stupid' compiler. But the reward is that EDL should it make easier to create a 'smart', faster compiler... The translation from statically typed Eek code to EDL will look quite unusual. For example, the following two methods will produce identical EDL code:

add1(int a, int b): int
        return a + b

add2(any a, any b):(any r)
        with a instanceof int, b instanceof int
        returns r instanceof int

        return a + b

The 'any' type is a late-binding reference type that I described here. In EDL all reference types are always equivalent to Eek's 'any'. The lines starting with 'with' and 'returns' are constraints that check the types of the input arguments and the return type. More on constraints in Eek here. So why does add2() have the constraints? The constraints tell the type-infering compiler that 'a' and 'b' are always integers. This allows the compiler to use the usual early-binding tricks. The compiler may also just remove the constraints, if all invocations of the method are guaranteed to use only integers. Or it may create two methods, one that keeps the constraints and one that doesn't. Right now, EDL is only described on a couple of OneNote pages. Many details are still open and I need to write it down in a more formal description. When this is done, I am going to post some examples of real EDL code.
written at 13:38. (0 Comments, Permalink)