Eek XML Code Snippets
Eek XML Code Snippets PHP5 has XML support built right into the language, somewhat similar to my Eek plan. Unfortunately, like so many other XML APIs, their namespace support is horrible. This makes the API useless, since all W3C Standards are built on namespaces and it's hard to do any serious XML work without them. Here is an overview over PHP5's XML capabilities. They have a couple of examples, and I try to port them to Eek's hypothetical XML API. Note that their first example shows PHP4's DOM API as a bad example, and I start at their second. Because Eek does not allow stand-alone code and I have no idea how to load an XML document yet, they will get the document as method argument instead of loading it using 'simplexml_load_file()'. So here is the first example, ported to Eek:

class EekXMLTest1
        processLibrary(<:library> library)
                for <:shelf> shelf in library..shelf 
                        Console.println("Shelf {shelf.@id}")
                        for <:book> book in shelf..book
                                Console.println("Title: {book..title}")
                                Console.println("Author: {book..author}")
end

The notation '<:library>' looks quite unusual, but it is just a convenience form of 'Element<:library>'. It declares an XML Element with ':library' as first class parameter. ':library' is a QName literal with the default namespace that specifies what kind of elements are allowed - only the '<library>' element is. '..' is the operator to access all elements with the name given as QName argument. So 'library..shelf' takes the Element 'library' and returns a list of all 'shelf' elements that it contains. The formal type of the returned list is 'ElementList<:shelf>'. Note that there is a special exception that allows the ommision of the colon (':') between the operator '..' and the QName. '.@' is used to access attributes, so 'shelf.@id' returns the content of the '.@id' attribute. Here's the second example, with namespaces (the 4th example in the text, as the third is another bad example):

namespace blog "http://www.edwardbear.org/serendipity/"
class EekXMLTest2
        processEntries(<:entries> entries)
                for <blog:entry> entry in entries
                        Console.println("{entry..blog:name}")

end

The most important thing is the 'namespace' declaration in the first line. It declares the identifier 'blog' to be a namespace. The prefix can then be used for QNames and in XML literals. The type '<blog:entry>' is a short form of 'Element<blog:entry>', an element which is guaranteed to be in the namespace defined by 'blog' and to have the local name 'entry'. The expression 'entry..blog:name' also uses the 'blog' namespace to access the 'blog:name' element. One last word about the 4th PHP example: the PHP example is already complicated, but it actually has two additional problems: it does not check whether the children of '<entries>' are actually '<entry>' elements, and it does not check the namespace of the '<blog:entry>' element. In a clean example it would be easier to see how bad the PHP syntax is for namespaces.
written at 00:37. (0 Comments, Permalink)

Eek Status Update
Two months ago I predicted that I will need two months to finish the specification and, surprise, I lied :). I am almost through the regular features, roughly comparable to Java's feature set. But the specification is still missing

• Generics/class parameters. I have a good idea what they will look like, as shown here, but writing it down will take same time
• Exceptions. No problem, but needs to be done.
• Constraints. Since my entry in february nothing has changed, I will probably specify them exactly as described in the blog
• Enum. Not a real problem.
• Annotations (alias attributes in C#). Will be very simple, just a list of Elements in front of classes and class members.
• Co-Routines/Generators. Should be easy.
• Delegates and Events. Now they are a real problem, actually the problem number 1. I have many different ideas, but am not happy with any of them. They will probably not look like described January
• Closures. The base idea is simple, code in curly braces ('{}') returns a delegate. But I don't know how to name arguments, this mostly depends on the missing delegate syntax.

written at 21:27. (0 Comments, Permalink)

Eek's Property Syntax
This old entry in Cedric Beust's (recommended) blog describes the differences of the property syntax in Java, C# and Ruby. So let's do it for Eek. There is one thing to say though, Eek does not make any difference between properties and fields. Everything is the same, and called properties. Read-Write attributes Eek knows two variants here. Either you can implement two accessor methods, or you write it like a Java field. In the first case the object does not have any memory associated with it, so you may want to have a private property to store the value. In the second solution, the object will have memory for the property, and accessors for reading and writing are implicitly created. You can still override them later without losing binary compatibility, but you don't have to write them as long as you don't need them. So here's the accessor method version:

public:
        String firstName.get()
                // some code

        firstName.set(String value)
                // some code

And this is the field syntax version:

public:
        String firstName

Read-Only Attributes Read-only properties can only exist as accessor methods, so there is no short notation. A true read-only field-like property would not make any sense in Eek. And I don't know a good syntax to define a field-like property with different access permissions for reading and writing.. So read-only properties can eiter be created by defining a 'get' method without 'set' method, or by definint the accessor methods with different access permissions:

public:
        String firstName.get()
                // some code
private:
        firstName.set(String value)
                // some code

written at 11:37. (0 Comments, Permalink)

Eek Code Snippets
Eek Code Snippets In order to get some more experience with Eek's look&feel, I started to reimplement small functions written in other languages. Preferable those that allow me to use Eek's advanced features. For example the famous Haskell implementation of Quicksort (intended to show how easy Haskell is, but more likely to be used as proof that the functional programming guys are.. special):

qsort []     = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
                 where
                   elts_lt_x   = [y | y <- xs, y < x]
                   elts_greq_x = [y | y <- xs, y >= x]

In Eek, using the beautiful closure filter operator '.()', a quicksort implementation could look like

class QuickSort
        static List<int> sort(List<int> list)
                int s = list[list.size / 2]
                return sort(list.(it <= s)) + sort(list.(it > s))
end

. This is an Eek version of the Binary Insertion Sort algorithm in Jeffrey Stedfast's blog (first example of the entry):

class BinarySearch
        static (int mid) sort(List a, int low, int high, int key)
		int range = low + high

		mid = (range + 1) / 2
		if (range % 2) == 1
			mid -= 1
	
		if key > a[mid]
			return sort(a, mid + 1, high, key)
		else if key < a[mid]
			return sort(a, low, mid, key)
		return
end

Nothing special here, just made the 'mid' variable a named return parameter. More examples will follow.
written at 01:24. (0 Comments, Permalink)