Eek - 10 months later
I started writing the Eek specification 10 months ago and my last summary was written in April '04, so I thought it would be nice to bring it up to date. The Eek specification is not done yet (5 pages left), but I don't expect any major changes. Eek is a strongly-typed, imperative OO-language with many similarities to Java, but enough details to make creating a new language worthwhile. Semantics

• everything is really an object, even numbers
• there are no static/class members, every member has an object
• support for singletons (as static replacement)
• there are no packages/namespaces, only classes that can be nested
• there are two kinds of references: those that allow null and those that forbid it
• there is no separation between properties and fields like in C# or Java, both are the same
• methods and properties can have Eiffel-like constraints
• built-in support for a XML-compatible data model called EXML, including literals for nodes and qualified names
• additional operators to allow EXML processing like the upcoming ECMAScript4XML (E4X) standard
• more logical control structures: any block can be prefixed by 'if', 'do', 'while' and 'for', and postfixed by 'else', 'until', 'catch' and 'finally'. You can combine a postfix and a prefix
• String characters are int
• no number types <32 bits, no unsigned numbers
• no (native) arrays
• a 'any' type that is a Object reference, but every method invocation or property access is checked at runtime. It thus behaves like a reference in a weakly typed language
• factory constructors that look like a regular constructor but act like a factory method
• virtual constructors that can be overridden
• support for tuples as return types and in assignments
• Developer has a choice between checked exceptions, like Java's, and unchecked like C#
• buzzwords: operator overloading, multi-methods, varargs, delegates, generics, exceptions, enum, foreach (but no C for), co-routines (with yield), closures, events

Syntax

• Java-like operators and keywords
• Python-like indentation for blocks (but without the colon) and statement-separation rules (no semicolons)
• no 'new' keyword, instantiation looks like C++ auto-allocation
• no parenthesis for control statements

Extendability Designed to make it easy to extend the language with new features. Possible extensions include a sister language that feels like a dynamic scripting language, based on the 'any' type.
written at 21:37. (0 Comments, Permalink)

Concurrency in Eek
Lamba the Ultimate links to a nice article about the upcoming performance challenges for CPUs. In the next few years, the single-thread performance of CPUs will slowly stop growing, and instead CPUs have to become faster by parallelization. I thought a lot about that topic in the summer, as I agree with the article's author that concurrency will extremely important for all system programming languages. However, my conclusion was that the langauge itself can not do much to make concurrency easier. There are many concepts like monitors, futures etc that try to make concurrency easier. Unfortunately they all fail, because none of them prevents the programmer from making stupid mistakes. Just forget to 'synchronize' or to put a lock around a variable access, and you have a bug that's hard to trigger but can cause fatal errors that are almost impossible to reproduce. My insight was that it is impossible to have a fool-proof way for two threads to use the same resource. So the only conclusion can be that this must be avoided at all costs, a resource should never be accessed directly by more than one thread. This lead me to a decent solution for many cases: split programs into many small modules that communicate using asynchronous messages. If more than one module need to work on a resource, this resource should be managed by a third module and the other modules need to communicate with the resource manager. Basically it is a service-oriented-architecture inside every application, with all SOA advantages like easy testing, buzzword-compatibility etc. I haven't found any reason why such a modularization needs to be integrated into the language though, so it's a pure framework feature (having EXML helps though). That does not mean that Eek won't have support for traditional multi-threading, it will have them at a level somewhat comparable to C#. And traditional multi-threading can make a lot of sense for performance reasons. Some selected modules/services benefit from supporting multi-threading internally, especially those that manage common resources. But that should be the exception, and the multi-threaded modules should be as small as possible.
written at 21:13. (0 Comments, Permalink)

Still not done...
Ok, I admit it, I am still not done. There are 7 pages left which contain only stubs right now (Exceptions, Constraints, Delegates, Closures, Events, EXML and the tokenizer) and I hope to have them soon. I am also considering 3 syntax changes at the moment:

• Removing the special notation for invoking delegates. There is no need for it, a delegate with the signature "delegate(String):int" is just a name for an interface that extends the IDelegate interface and adds a method "call(String):int". "call" is the identifier of the method, and the only magic of delegates in Eek is that Eek makes a compile-time guarantee that a delegate has a method named "call" with delegate's signature. So why not simply invoke "call()"? I do remember that examples of C# with its delegate invocation syntax confused me when I first saw them; delegates are not invoked that often, and so I think I can just live without it.
• Changing the syntax for generics/class parameters. Right now, all class parameters are specified in angle brackets ("<>"), but I never really liked using relational characters as brackets, even if C++ and now Java do. The clean alternative would be to use regular brackets ("[]", do they have any special name?):

  class Stack[Object T]
          private Array[T] mArray
  
          push(T obj)
                  // ...
  
          pop(): T
                  // ...
  
  // ...
  add[Number T](T a, T b): T
          return a + b
  // ...
  delegate[Number T](T,T):T myGenericDelegate = closure[Number T](T a,T b):T { a + b } 
  

  It may take a while to get used to it, but it's easier to type and to read.
• To avoid confusion, I would then replace the index operator ("[]", the one used to access arrays in C++ and Java) with the 'at' char. So instead of "x[4]" I would write "x@4" to access the fourth element. It is not as nice to write and read as brackets, but I expect the index operator in Eek to be far less frequently used than class parameters.

written at 01:47. (0 Comments, Permalink)