I've found 2 good uses of the new goal directed execution of Loell. One is that failure together with else works the same as throw and catch in Javascript. The other one (maybe rather obvious) is assertions. To the shapes example I added this precondition to the moveTo method:

pos {.x isA Number gt 0;.y isA Number gt 0};

Which means that pos has to be an object with 2 properties, x and y, which both have to be of type Number, and greater than 0. You see that you don't have to write .x isA Number;.x gt 0. This is because the methods that previously returned a boolean value, now return this (the left-hand expression) instead of true. In Icon tests return the right-hand expression with success, but I figured the left-hand side makes more sense in an OO language.

Inspired by an article on Ltu today, I implemented a goal directed programming feature into Loell. No more booleans, instead there are now success and failure. When an expression returns failure, the whole closure immediately returns failure. This was only a small change in the code, and the examples hardly changed. I only had to add else success to the while code to indicate that failing the while test is not a failure. I haven't found a really cool example for this yet, but you can try the following in the shapes example:

scribble each {that isA Shape}

This will test if the scribble list only contains shapes. (Remember that that is the default method argument)