More on Plastic


I’ve added some more features to my toy language “Plastic”.

Partial application of function arguments.
This is now used for generators.
Yield is no longer a core function, instead, each generator takes a closure as its last argument which is then supplied by the foreach function.
This way the foreach body don’t have to be stored as a symbol, it is just passed as an argument to the generator.

func Range(low,high,yield)
{
    for(let i=low,i<=high,i++)
    {
        yield(i);
    };
};

// apply value to "low"
let From10 = Range(10);

// apply value to "high"
foreach(x in From10(20))
{ //this block is transformed to a closure and passed to yield
    print(x);
};

Break and Continue
Loop behavior can now be altered with break and continue.
I implemented those as special values that breaks any execution flow almost like exceptions.
The values are then bubbled up to the first loop which consumes the values and perform the appropriate action.

I guess exceptions and “return” could be implemented the same way.

[Edit]

I’ve added some basic one way coroutine support to support breaking out of generators that are constructed from nested loops.
Before, a break would only exit the most inner loop of the generator.

Now I can do things like this:

func primes(low,high,yield)
{    
    foreach(i in range(low,high))   
    {             
         foreach(j in range(2,i/2))        
         { 
             if (i % j == 0)
             {
                break;
             };
         }
         else
         {  
             yield(i);
         };         
    }; 
};


foreach(prime in primes(2,100))
{
    print(prime);
    if (prime > 50,break);
}
else
{
    print(""done"");
};

Plastic – Added generator support


I’ve added generator support to my toy language “Plastic”.
It’s quite funny how easy it is to implement some language features once you understand how they work behind the scenes.
At first, I thought generators would be extremely hard to implement, requiring AST transformations to build state machines a’la C# for enumerable methods.

But my java script guru colleague Sebastian Markbåge stated “its simple, just invoke the for each body as a closure from the generator when you hit yield”.
It’s so brilliant, no AST transformations and I could implement the whole thing in less than 20 LOC.

This enables me to write code like this:

//a generator function
func Range(low,high)
{
    for(let i=low,i<=high,i++)
    {
        yield(i); 
    };
};

//loop over the generator values
foreach(x in Range(5,20))
{
    foreach(y in Range(1,2))
    {
        print ("yielded " + x + " " +y);
    };
};

Looks like a real language almost, doesn’t it? :-)

So what going on here?

Well, the foreach function creates a closure of its own body with a single in argument, this closure is then stored and the generator function is invoked.
Once the generator calls the “yield” function, the yield function will route the yielded value into the closure of the foreach body.
This works fine even for nested loops.

Playing with Plastic


As some of you might know, I’ve been fiddling with a generic DSL grammar, here and here.

I figured that I should do some proof of concept on this and started to write a language using the grammar and parser.
Since I’ve already created a LISP clone earlier, I thought I should go with something similair, but using my C like grammar.
The evaluator is beeing developed using F#, a wonderful language for this kinds of things, forget any bashing I’ve done on F# ;-)

The results of my experiments is a language that is somewhat similair to JavaScript, but with LISP’ish macro support.
I lie if I say it’s real macros, but I can get similair results as LISP macros.

How it works:

The C# based parser parses the source code and returns a generic AST.
I then use F# to translate the generic AST into a similair F# based AST, just to make it easier to consume it from F#
The F# AST is then passed to my F# evaluator, which simply traverses the AST and evaluates the branches in the AST.

F# does an amazing job here, the AST evaluator is only around 150 LOC and some 100 LOC for the core functions, like “if” and “func”.

With these 250 lines of code, I get features like:

Macro like functions:

func for(ref init,ref cond,ref step,ref body)
{
    init();
    let result = null;
    while(cond())
    {
        result = body();
        step();
    };
    result;
};

//makes it possible to do:
for(let i=0,i<3,i++)
{
    print(i);
};

Chained expressions:

The macro like support allows me to add new constructs to the language, unlike other languages
like Boo or Ruby where you can pass closures as the last argument to a function, I can pass an entire chain of functions or expressions as the tail argument.
thus allowing constructs like:

if(x)
{
}
elif(y)
{
}
else
{
};

Note that “;” terminates a chain, which is the reason why there is a “;” at the end of a “for” block for example.
This is the reason I picked the somewhat corny name “Plastic” for the language, because it can be molded to support new consturcts.

Passing functions:

//passing functions
func f(x)
{
    x + 3;
};

func g(function,x)
{
    function(x) * function(x);
};

print (g(f,7));

Returning functions(closures):

func makefun()
{
    let x = 10;
    func()
    {
        x++;
        print(x);
    };
};

let fun = makefun();
fun();
fun();
fun();

There is still lots of things I want to add, e.g. There is no OO support at all right now, nor is there any way to deal with simple things like arrays.
So there is more to come.

Genetic Programming: Evolving Domain Logic a’la CQRS


[EDIT]
This was supposed to be my contribution to first of april (Sorry guys)
But apparently people are already doing things similair to this, for real, which makes this post quite a bit less fun.

So maybe aprils fool is on me if someone implements this :-)
[/EDIT]

Most samples of genetic/evolutionary programming evolve formulas, e.g. a single mathematical formula that evolves to come up with a formula a given set of in and out parameters.
(see http://rogeralsing.com/2010/02/14/genetic-programming-code-smarter-than-you/)
While that is interesting, it would be much more interesting and profitable if one could evolve an entire application, or at least some parts of it.

If you are into domain driven design, you have probably seen that the latest buzz is CQRS, Command Query responsibility segregation.
In short, you let your domain model raise events that can be consumed by a query/reporting store.
Thus, allowing the query and command sides to be separated.

So what does this have to evolving code?
Well, if you want to evolve code, you need some way to verify the fitness of it, how good the generated code solves your problem.
This is hard if not impossible to do for a normal application, there is no natural integration point where you can see if the application does what you expect.

However, with domain logic a’la CQRS, you have domain events, and you can easily set up a set of event sequences for a given use case.

Example.

Given that:

Customer.Rename("Foo");
UoW.Commit();

Expect:

CustomerRenamedEvent
  CustomerId = 123
  NewName = "Foo"

Given that:

Customer.Rename("Bar");
UoW.Commit();

Expect:

CustomerRenamedEvent
  CustomerId = 345
  NewName = "Bar"

Or preferably a more complex scenario

Given that:

Customer
 .NewOrder()
 .AddProduct(50050,10)
 .AddProduct(1024,5)
 .AddProduct(50040,2);
UoW.Commit();

Expect:

OrderPlacedEvent
  OrderId = 1
  CustomerId = 2
   Details
      OrderDetail
         ProductId = 50050
         Quantity = 10
      OrderDetail
         ProductId = 1024
         Quantity = 5
      OrderDetail
         ProductId = 50040
         Quantity = 2

This way, you can compare the expected output with the output of the generated code.
You simply have to score the events based on if they match the expected types and if they contain the correct data.

You will still have to create skeleton code for your entities and event types and describe the expected output, but the actual implementation can be generated by evolution.
That is, it will evolve the command methods that performs domain logic and changes state in your model.

In my experiment it takes on average 7-9 minutes for my POC generator to come up with C# code that solves the given problems, per command method that is.
(About 43 k generations)

IMO this is groundbreaking since the code don’t have to be tested since you already know it fills your expectations and even in complex cases the generator is usually faster than most junior developers.

A very nice benefit of evolution is that if you later get some changed requirements, some special cases, the evolver can simply continue from the current code and incrementally add the code for the new requirements.

Since the fitness factor currently doesn’t include how complex the generated code is, the output can be somewhat verbose.
Actual sample:

public void Rename(string newName)
{
     this.Name = (newName + "a¤").Substring(0, newName.Length - 9 + 5 + 4);
}

This can be solved by giving short code higher fitness than equal but more verbose code.

Thats all for now..