Yeti is a functional language for the JVM, which is statically typed with full type-inference, powerful functional abstractions and structural-typing therefore allows much shorter code than Java. In this respect it is similar to scala but much simpler both in the type-system and  in the language features. (The language-tutorial is quite short and can be found here: http://linux.ee/~mzz/yeti/intro.html)

By now I have done quite a bit of classical JVM programming with yeti and just wanted to test whether it also works for Android, because I thought it would be perfect for Android as well. Not just because it has the mentioned advantages over Java, but also because it has a smale language-api (about 177 KB) and because it is compiled and so quite fast.

In this post I want to show how to setup an Android project using ant to compile with yeti and in the end how to do the same thing with maven.

Prerequisites

1. If you don’t have it already, install the android-sdk and eclipse with the android plugin (http://developer.android.com/sdk/installing.html)

2. Download the yeti.jar to its own directory this includes the compiler http://linux.ee/~mzz/yeti/yeti.jar

3. Download the yeti-lib.jar this are only the runtime-classes without the compiler http://linux.ee/~mzz/yeti/yeti-lib.jar

(Alternatively you can also get the sources from github (git clone git://github.com/mth/yeti.git) and run ant for the yeti.jar and ant yeti-lib for the lib jar)

Create a new Eclipse project with ant support

1. In eclipse create a new Android Activity project. Exactly as described in the Android  “Hello World Tutorial: Create a New Android Project “: http://developer.android.com/resources/tutorials/hello-world.html#create

3. Run the newly created project from Eclipse (press the green run button and run as Android Activity)

2. Create an ant build.xml for your project: Open a command prompt and navigate to the base directory of you project and type android update project – path .

>android update project --path .
Updated local.properties
Added file c:\workspace\helloandroid\build.xml

If the android command is not found on the path then you need to update your path to include the Android tools. On windows at to the Path %ANDROID_HOME%/tools, where %ANDROID_HOME% points to the installation-directory of the android sdk.

Add yeti-lib.jar Update build.xml and add –post-compile target with the yeti compiler

1. Create in the base directory of your project a directory libs and copy the yeti-lib.jar there.

2. In eclipse right-click on the yeti-lib.jar and add it to the projects build-path.

3. modify the ant build.xml file to add the –post-compile target with the yeti compile task:

   <!-- insert following in build.xml before the already present <setup/> tag -->

    <!-- define the yeti compiler task -->
    <target name="yetic-def">
        <taskdef name="yetic" classname="yeti.lang.compiler.YetiTask"
                 classpath="C:/yeti/yeti.jar"/> <!-- path to where you downlaoded the yeti.jar -->
    </target>

    <!-- compile yeti sources after java sources have been compiled -->
    <target name="-post-compile" depends="yetic-def">
		<yetic srcdir="${source.absolute.dir}" destdir="${out.absolute.dir}"
			   includes="**/*.yeti"
			   preload="yeti/lang/std">
			<classpath>
				<path location="${out.absolute.dir}"/>
				<pathelement location="${android.jar}"/>
				<fileset dir="${native.libs.absolute.dir}" includes="*.jar"/>
			</classpath>
		</yetic>

    </target>

	<!-- continues original build.xml -->
	<setup />

</project>

Update the build configuration of the eclipse project to include the yeti compiler ant-task

In eclipse you can update the builders property to run the yeti compiler each time files are saved and modified. Because the yeti compiler is very fast this does not hinder your workflow.

1.) right-click on your project –> select properties –> choose Builders

2.) Create a new Ant Builder name it yetic

3.) in the first tab “Main” choose for “Buildfile:” the ant build.xml file we just have modified before, make sure the “Base Directory:” is ${workspace}/yourprojectname

4.) on the “Targets” tab choose in both “After a Clean” and “Auto Build” the –post-compile target from the build.xml

5.) press ok

Finally rewrite your  HelloAndroid.java file in yeti and run it

1.) delete the HelloAndroid.java file

2.) and rewrite the content of the HelloAndroid.java file in yeti: Create a file named “yetihello.yeti” in the same package as the HelloAndroid.java activity was and add the following content

module com.example.helloandroid.yetihello;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.widget.TextView;

class HelloAndroid extends Activity
	void onCreate(Bundle savedInstanceState)
		super#onCreate(savedInstanceState);
		tv = new TextView(this);
		tv#setText("Hello, Yeti on Android");
		this#setContentView(tv),

end;

()

3.) Press Run again for Hello Android

Using Maven to build Android Application

Finally I want to mention that you can also use maven-android-plugin together with the yeti-maven-plugin to build android applications using maven. All you have to do is setup a maven android project as described here  http://code.google.com/p/maven-android-plugin/ and add the yeti plugin as described here  https://github.com/chrisichris/yeti-maven-plugin. You should replace the dependency on yeti.jar with yeti-lib.jar and add the property yeti-full-jar=false in the yeti-plugin’s configuration section

<!-- yeti-lib dependency -->
<dependency>
	<groupId>org.yeti</groupId>
	<artifactId>yeti-lib</artifactId>
	<version>0.1-SNAPSHOT</version>
</dependency>

<!-- yeti plugin -->
<plugin>
	<groupId>org.yeti</groupId>
	<artifactId>yeti-maven-plugin</artifactId>
	<version>0.1-SNAPSHOT</version>
	<executions>
		<execution>
			<goals>
				<goal>compile</goal>
				<goal>testCompile</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<yeti-full-jar>false</yeti-full-jar>
	</configuration>
</plugin>

As it is easy to code regular Java classes in yeti you can write JUnit TestCases and do your unit-testing that way. However in this post I want to introduce you a more ‘yetish’ approach using yebspec a very simple test-module which is a somehow between classical unit-testing and the scala Behavior Driven-Design (BDD) test-framework specs.

Yebspec is implementation-wise a very simple test-helper. It is just one module in the yeb project (https://github.com/chrisichris/yeb) a still very alpha project for yeti. However yebspec is the part of the project which is most stable (and used).

In this blog-post I want to first show

1. how to write a yebspec test than
2. how to run it from the console or through JUnit integration and finally
3. a bit how it is implemented

Writing Specifications to Specify and Test your code

As said yebspec is implementation wise a very simple framework – much simpler than i. e. scala specs. All it does is to collect and report AssertionFailedError which might be thrown inside user defined specification functions by assert functions – exactly like in JUnit.

Describe what Something Should do

You basically create a dedicated spec module (similar to JUnit TestCase class) and define different specifications and assertions in it. This module can than be run and return a result-summary, which can be printed out or otherwise reported and analyst.

Let’s look at an example, where we test part of the yeti.lang.std module:

module example.stdSpec;

load org.yeb.yebspec;

specificationsFor "the yeti.lang.std module which is implicitly loaded in yeti"\(

    specification "for the list manipulation funtions" \(
        baseList = [1 .. 20];

        describe "map" \(
            should "apply function to each element" \(
                r = map (+2) baseList;
                assertEquals [3..22] r;
            );
            should "work on empty lists as well" \(
                assertEquals [] (map id []);
            );
        );
    );

    specification "for the string functions" \(
        describe "strLength" \(
            should "give right length" \(assertEquals 3 (strLength "123"));
        );
    );
    //just describe threadLocal
    describe "peekObject" \(
        should "read struct" \(
		      ......
        )
    );
);

To define specifications a new module is created. The result of the modules is the result of the one specificationsFor function.

The specificationsFor function takes a descriptive string and a function argument – \() – which gets evaluated once each time the result of specificationsFor is evaluated.

Inside the argument function the functions specification, description and should (collectively called subSpecs) are called which in turn take a description-string and a function argument, which can recursively  contain again subSpecs and different assert statements.    From the code-logic point of view there is no difference between specification, describe und should. They are all the same function only with a different name for better readability.

To compare this with JUnit: The module plus the specificationsFor function is similar to a TestCase class, the subSpecs (specification, describe, should) are the test-methods and which contain assert statements

Asserting Behavior

Like in JUnit in yebspec different assert functions can be used to assert that code does what it should do. (In BDD it is a central concept to use different names for assert, because there you do not test something but describe it, however yebspec uses assert like JUnit)

The assert statements must be executed in one of the subSpecs (specification, describe, should) argument functions. Like their JUnit counterparts assert functions throw junit.framework.AssertionFailedErrors if the assertion does not hold and this error is caught by the subSpecs and collected to report.

There are many different assert functions. Basic ones (fail, assertTrue, assertFalse, assertEquals, assertNotEquals, assertSame, assertDefined), some for lists (assertEmpty, assertNotEmpty, assertContains, assertContainsAll, assertEqualsElements) and some  for Exceptions (assertException, assertFailWith, assertExceptionIs). (To see how to use them it is currently best to look at the source code of src/main/java/org/yeb/yebspec.yeti module at https://github.com/chrisichris/yeb)

If you want you can add a description to an assert using the assertLabel function:

assertLabel "some description" \(assertTrue someCondition);

Writing a new assert function is simple. Just check the condition and if it fails call testFail with the assert specific message. For example assertEquals is implemented this way:

assertEquals right test =
    if right != test then
        testFail ("Should be [\(right)] but was [\(test)]")
    else () fi;

The testFail function will throw the right exception and take care that the assertLabel is added.

Fixtures

The argument functions to specificationsFor and the subSpecs are normal yeti functions. Any code can be executed in them and the subSpecs are also normal functions which are invoked – no magic here.

Therefore all normal yeti idioms can be used to define fixtures etc. There is no need for setUp() tearDown() methods.

To define a fixture which is fresh for each ‘should’ you generally do the following:

describe "array functions" \(
    shouldFX desc fn =
        should desc \(fn (array [1,2,3]));

    shouldFX "push" do ar:
        push ar 4;
        assertEquals (array [1..4]) ar;
    done;

    shouldFX "shift" do ar:
        assertEquals 1 (shift ar);
        assertEquals (array [2,3]) ar;
    done;

);

Here we define our own should function shouldFX. It takes the description-string and a function which gets a fresh array as test data. The shouldFX function than calls the standard should with the provided function with a fresh array. And then the shouldFX function is used like the standard should function to test the push and shift array functions from yeti.lang.std.

If you have to do some clean up you should wrap the provided function call in a try finally yrt (as standard in Java or yeti):

shouldFX desc fn = should desc \(
   stream = ....
   try fn stream finally stream#close() yrt
);

To have a test-environment which you do not want to setup for each ‘should’ because it is too expensive (i.e. in integration testing a long starting service), you just wrap many should in a try finally yrt:

describe "expensive service" \(
	service = ....
	try
		should "provide this" \(..);
		should "provide that" \(..);
		....
	finally
		closeService service;
   yrt;
);

This is all standard yeti. There is no support form yebspec for fixtures, test-environments etc. because yeti provides it more concise itself than the framework could do.

Composing a Suite out of different Yebspec Modules

Like in JUnit different yebspec modules can be combined in a suite which looks to the outside itself like a yebspec. Suites can be combined themselves in suites and so on.

This comes handy if you want to run all the tests form one place or combine different places.

To do so define a module with the specSuite function which takes a list of yebspec modules:

module example.allSpecSuite;

load org.yeb.yebspec;  

specSuite "all specs for yeti lang"
        [load example.stdSpec,
         load example.ioSpec,
         load example.fooSpec
         ]

Running from the Repl and JUnit Integration

A specification module can be run from the regular yeti-console, more convenient through the  yeti-maven-plugin repl and through JUnit for build-tool and ide-integration.

Running from the regular console

yeti>ys = load org.yeb.yebspec;
...
yeti>res = (load example.stdSpec) none
....
yeti>ys.printResult print res
....

First the yebspec module is loaded, than the spec we have defined is evaluated and finally the result is printed.

There is a lot of uninteresting intermediate output, so you generally do this in one line:

yeti>(load org.yeb.yebspec).printResult print ((load example.stdSpec) none)
-------------------------------
 Y e b   Y e t i   S p e c s
-------------------------------
success:   specifications for: the yeti.lang.std module which is implicitly loaded in yeti (s:6, f:0, e:0)
  success:   specification: for the list manipulation funtions (s:4, f:0, e:0)
    success:   describe: map (s:2, f:0, e:0)
      success:   should: apply function to each element
      success:   should: work on empty lists as well

    success:   describe: array (s:2, f:0, e:0)
      success:   should: push
      success:   should: shift

  success:   specification: for the string functions (s:1, f:0, e:0)
    success:   describe: strLength (s:1, f:0, e:0)
      success:   should: give right length

  success:   describe: peekObject (s:1, f:0, e:0)
    success:   should: read struct

Result: SUCCESS:
Specs run: 6, failed:0, exceptions:0
===== E N D   Y e b   Y e t i   S p e c s

Running from the yeti-maven-plugin Repl

If you are using the yeti-maven-plugin (which is handy when developing with yeti see a previous blog-entry) there is additional support.

Especially you can run all or certain specs automatically each time you change a source-file. This is very helpful during development, because yeti immediately recompiles the tested source file and test it. This is very similar to what you get through modern Java-IDE’s instant-error reporting and even more because it does not only report compile errors but also test errors. And it does not hinder the workflow because yeti is fast – very fast. This way you get nearly both the interactive development features of dynamic language with the compile time safety of static-languages.

To enable the additional maven support add the yeb dependency and configure the maven-yeti repl to automatically load the org.yeb.yebshell module.  The org.yeb.yebshell module is the helper module which provides i.e. the repl support for yebspec.

pom.xml:

<dependency>
    <groupId>org.yeb</groupId>
    <artifactId>yeb</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

<plugin>
    <groupId>org.yeti</groupId>
    <artifactId>yeti-maven-plugin</artifactId>
    .....
    <configuration>
        <commands>
            ys = load org.yeb.yebshell;
        </commands>
    </configuration>
</plugin>

Start the maven repl from the command line and call –ys.checkSpec “module.name” to run spec once and  –ys.monitorSpec “module.name” to run a spec each time a source file is changed:

C:\yeti\example>mvn -Dyetic=false clean yeti:repl
......
yeti>-ys.checkSpec "example.stdSpec"
......
yeti>-ys.monitorSpec "example.stdSpec"
.....

Note the module-name is given as a string. This is because the tests are executed in an extra repl.

Use –s.showMonitors () to show all current monitors and –s.removeMonitor id to remove a monitored spec.

JUnit integration

JUnit is of course excellent integrated in build-tools and IDEs etc – something yebspec is indeed not . However yebspec uses JUnit as a brigde to get to the same support us JUnit has ie nice graphical output from IDEs, automatic testing through maven ant etc.

If you want that – and you propably do – just create a Java JUnit TestCase class and load into the suite() method all the tests in your yebspec. To JUnit (and all the tools) this than looks than exactly like a regular JUnit 3 TestSuite:

package example;

import junit.framework.Test;
import junit.framework.TestCase;
import org.yeb.YebUtils;

public class StdSpecTest extends TestCase {

    public StdSpecTest(String testName) {
        super(testName);
    }

    public static Test suite() {
        Test suite = YebUtils.createSuite("example.stdSpec");
        return suite;
    }

}

That’s it now all your specs are run and reported as JUnit Tests by maven, Netbeans etc.

Implementation

As said the implementation is actually very simple. It is just one module where half of it is assert definitions and reporting. You can take a look at this module at the git-hub projects site in src/main/java/org/yeb/yebspec.yeti

At the core there are these functions

_newNode name is string -> resultNode = (
    {name,
    var parent = none,
    var children = [],
    var result = Right (),
    var msg = "",
    var rights = 0,
    var fails = 0,
    var exceptions = 0
    }
);

_parentNodeTL = (x is None () | Some resultNode = none; threadLocal x);

_specs maybeParentNodeIn name action is ( None () | Some resultNode ) -> string -> (resultNode -> 'a) -> resultNode= (
    //executes given action on each node and all its ancestors (parents)
    withParents node ac = (
        ac node;
        case node.parent of
            None _ : ();
            Some n : withParents n ac;
        esac;
    );

    maybeParentNode = case maybeParentNodeIn of
                         None _: _parentNodeTL.value;
                         Some _ : maybeParentNodeIn;
                      esac;

    //creaet node for esecuting this
    myNode = _newNode name;
    myNode.parent := maybeParentNode;
    case maybeParentNode of
        None _: ();
        Some pn : pn.children := pn.children ++ [myNode];
    esac;

    //set our node as the new thread local
    oldTLV = _parentNodeTL.value;
    _parentNodeTL.value := Some myNode;

    //execute
    try

        _ = action myNode;
        myNode.msg := "";
        myNode.result := Right ();
        if empty? myNode.children then
            withParents myNode do n: n.rights := n.rights + 1 done;
        fi;
    catch AssertionFailedError ex:
        withParents myNode do n: n.fails := n.fails + 1 done;
        myNode.msg := "fail: \(ex#getMessage())";
        myNode.result := Fail ex;
    catch java.lang.Exception ex:
        withParents myNode do n: n.exceptions := n.exceptions + 1 done;
        myNode.msg := "exception: \(ex)";
        myNode.result := Exception ex;
    finally
        //reset the parent node
        _parentNodeTL.value := oldTLV;
    yrt;
    myNode;
);

specificationsFor name action maybeParentNode =
     _specs maybeParentNode "specifications for: \(name)" action;

_subSpec specName name action = (
    _ = _specs none (specName ^ name) action;
   ()
);

specification name action = _subSpec "specification: " name action,
describe name action = _subSpec "describe: " name action,
should name action = _subSpec "should: " name action,

The central function here is _specs. This function takes an optional parent node (a node is a structure which describes in a tree the result of the evaluation of a subSpec) a description and a function which it executes and return a result node. If no parent node is given it checks he ThreadLocal _parentNodeTL for one. Than it creates a new node for its own result and adds it to the parent node (if there is one). And than it binds its new node as the parent-node to the ThreadLocal.

After that it just executes the given function and catches any AssertionFaildErrors or other Exceptions and adds the result of a failed or successful run to the node (and its parents).

The specificationsFor and specification, describe and should functions just delegate to the _specs function. The specificationsFor returns the node which can than be printed, analyzed, used for JUnit integration etc.

Finally

Well that’s about it. I think the most important point here is probably that you see how easy it is to write useful code in yeti.

Hope you like it and hope even more you comment on it. It just more rewarding if there are comments positive but of course also critiques.

In  this post I want to show how the flexibility of yeti’s type-system can be used to do type-safe dependency-injection (DI) with very little code.

Before I come to the dependency injection part I want to introduce Yeti’s structural type-system, which is the reason you can do DI in the way I’ll show and which is at the same time quite different from the nominal type-systems used in most other languages like Java, C# or mainly Scala.

When it walks like a duck and swims like a duck, can you see it as a duck?

The answer to this question depends on the type-system.  (Note I only speak about static type-system in this post).

In Java, C#, Scala  type-names (or class-names) matter. In these languages only instances of the class with the same name (and its explicitly by name declared subclasses) have the same type and can therefore be used interchangeable. Instances of other classes have a different type no matter whether they possibly have exactly the same fields and methods or even have the same code apart of the their name – no duck-typing here. Types are differentiated in these languages by their defined names. Therefore the type-systems of these languages are called nominal type-systems.

Contrary in yeti every data-structure and each function which is composed of the same elements has exactly the same type – no matter how it is called. Names – if there are any at all – are just cosmetic. In OO terms you could say that if two objects have the same fields and methods than they always also have the same type and can be used interchangeable regardless of their class.

Actually in such a OO-language you would not have to explicitly define classes, because if you create an object with the methods void duckSwim() and void duckWalk() than it is automatically a member of the class of objects which can be used (seen) as a duck. And for the same reason in Yeti you do not have to define a named type or class and you even can not define a named type or class (you can define aliases but these are just shortcuts and you can for Java interoperability define Java-Classes but this is a different story).

In (pure) Yeti you just create a list, a structure, a function and if it has the same element-types like another list, structure etc. than it has the same type. And if a function accesses a field duckSwim on its argument and than calls the field’s value as a function than the compiler knows this parameter belongs to the set of structures (think records) which have a duckSwim field which in turn holds a function. And the compiler than requires the caller of the function to provide such a parameter, but how this is created, where it comes from, whatever other fields it has is unimportant.

Ok so lets first look at structures a bit closer with a small example so that we than have everything together for the main – the DI part.

Structures as Record Data-Types

Yeti has built in  primitive types (boolean, number, string and unit), function types and compositional types, which are used to compose all other types.

One of the built in compositional types are structures.

Structures are record data types that contain one or more named fields. Each of the fields can have a different value and has in turn its own type.

Structure values are created using structure literals, which contain in curly-braces one or more field definitions, separated by comma. Each field can contain any value – also functions or other structures. The values of a structure are accessed using the dot plus field-name.

>pl = { distance = 2345,
            name="Jupiter",
            star= {name = "Sun", volume = 345},
            rotate speed = .... //some function here
         } 

>println pl.name
"Jupiter" is string

Like you see we did not define a class “Planet” or so. We just created the runtime-instance very much like a dynamically typed data-structure, but still the compiler can calculate a type for each field as if we had defined a class – just without a name.  If you are interested in the type the compiler infers, you can enter the above structure at the yeti-repl (all in one line) and it will print out the full-type.

And if we write a function which i.e. prints out the star of a planet, we also do not have to first define a class planet to define the function argument type:

printStarOfPlanet planet = (
     planetName = planet.name;
     starName = planet.star.name;
     println "\(planetName) belongs to \(starName)"
)

Here we also work very much like with a dynamic data-structure, but also this one is statically type-checked, because the compiler demands that the parameter planet has a name field and a star field which in turn has another name field. The compiler however does not demand that the structure has a distance or rotate field. It can have other fields but it does not have to. In fact any structure which has the name and star.name field can be printed with printStarOfPlanet.

It is obvious that this provides a lot of flexibility, because you do not have to define interfaces, sub-type-relationships etc. beforehand, but can just mix and match the demanded fields as needed when you create the structure.

So lets use that to tackle the common task of dependency-injection in a statically type checked manner, in a (possible) hierarchical fashion and scoped. And all that straight forward just in plain yeti  without any magic DI-framework.

Elegant type-safe Dependency-Injection

The example is an extended form of the example used in the excellent blog-posts: ”Pushing the envelope on OO and functional with Scala” by Debasish Ghosh and “Real-World Scala: Dependency Injection (DI)” by Jonas Bonér. This blog-posts are as their name say about DI in Scala, which is of course another very powerful modern JVM language – with a much more powerful type-system and feature-set than yeti but also more complicated (especially to read and understand).

To make things a bit more realistic and to show some features we use a few components:

1. A requestHandler function which handles a HttpServletRequest, loads the current user from the session and than delegates to the renderPage function
2. the renderPage function that renders the html and uses the productService to render the product-of-the-month recommended to the current user
3. the userService – which for the example just delegates to the DAO
4. the productService – which also just delegates to the DAO
5. and a DAO for both the userService and the productService; one dummyDAO and one productionDAO
6. a HttpServlet which plumbs all together

I will not implement the full code just what is needed to show the DI concept, but still this sounds like a lot of code and interfaces just for a blog-post. Well just scroll down to the end of the post to see all the code together.

First we implement the userService and a dummyDAO. We put all the code in the yetidi.yeti file, which is the module which contains all the code.

module yetidi;

import javax.servlet.http.HttpServletRequest;

di = {

    userService ctxt = {
        loadUser userId = ctxt.userDAO.readUser userId,
        storeUser user = ctxt.userDAO.createUser user.name user.userId,
        removeUser userId = ctxt.userDAO.deleteUser userId,
    },

    dummyDAO = {
        readUser name = {userId = name, name = name},
        createUser name uid = {userId = uid, name = name},
        deleteUser name = true,
        readProduct name = {itemNumber = name, name = name}
    },
};

di

Like in a typical yeti module we create a main structure which contains all the fields/functions of the module and return that at the end. (We store the main-structure in a variable, because we will need it for testing- which we do for brevity just in the module and we also want to put the HttpServlet class in the same module and this has to access this structure).

First you will note that we do not define any interfaces or classes, we code right away the implementation of the production and dummy components.

The first function userService takes a ctxt (context) argument and creates a structure which loads, stores, removes Users – the userService. The userService in turn looks up its DAO in the passed in context.

You might wonder why a context is passed in and not the userDAO directly. The reason is that the userService could itself create another component with dependencies. Now instead of declaring this additional dependencies the userService just passes ctxt further and the compiler will itself take care (infer) that the context has all the dependencies. We will see that later in the requestHandler function.

As the userService delegates all calls to the userDAO we also create a dummyDAO with the needed functions (see again no interface here).

Before going further the dummyDAO is used to test the userService. At the following two lines to the very end of the module (until the ——) and load the module in the repl.

uS = di.userService {userDAO = di.dummyDAO};
uS.loadUser "foo";
--------
//result is:
{name="foo", userId="foo"} is {name is string, userId is string}

First the userService is created, using our dummyDAO and than we load the user “foo”. As expected this returns a structure with name=”foo” and userId=”foo”. Note that the compiler has inferred the full-type {name is string, userId is string}.

Everything is fine so we go on with the productService:

productService ctxt = {
    loadProduct name = ctxt.productDAO.readProduct name,
    productOfTheDay userId = (
        u = ctxt.userService.loadUser userId;
        //choose some product for the user and load it
        loadProduct "itemFor-\(u.name)"
    ),
},

dummyDAO = {
    readUser name = {userId = name, name = name},
    createUser name uid = {userId = uid, name = name},
    deleteUser name = true,
    readProduct name = {itemNumber = name, name = name}
},

The productService is similar implemented as the userService: It takes a context from which it looks up its productDAO and just delegates to it.

Additional it provides a productOfTheDay which is used by the view to show an advertisement for a given customer. The productOfTheDay function in turn uses the userService. So the productService has two dependencies the productDAO and the userService.

Finally we just extend our dummyDAO with the readProduct function – in production we could separate the DAOs.

Lets test it again:

uS = di.userService {userDAO = di.dummyDAO};
pS = di.productService {productDAO = di.dummyDAO, userService = uS};

pS.productOfTheDay "Joe";
-------------------
{itemNumber="itemFor-Joe", name="itemFor-Joe"} is {itemNumber is string, name is string}

Again we first create the userService , than we create the productService injecting the productDAO and the userService we have just created. And finally we get as expected an item with the right type. Note that we have not once defined a type or interface, no parameter type, no item class, no return-type nothing.

But could we now test the productDAO without using the real userService? Sure:

pS = di.productService {productDAO = di.dummyDAO,
                        userService = {
                            loadUser ui = {userId = "foo\(ui)",
                                               name = "foo\(ui)"}}};
pS.productOfTheDay "Joe";
------
{itemNumber="itemFor-fooJoe", name="itemFor-fooJoe"} is {itemNumber is string, name is string}

This time we inject through the context a mock userService which we create on the fly. And additional we only implement the function which is actually needed by the productService (loadUser) and not all the functions which are by chance on a fictive interface of userService because the “interface” of userService from the point of the productService is just the function loadUser. That’s what the compiler says, because all this is still completely statically type-checked. I.e. If we would misspell laodUser the compiler would immediately complain.

The final two pieces of our puzzle are the requestHandler and the renderPage. Both are just functions not structs, because the only do one thing (which is nice because yeti is after all a functional language):

    requestHandler ctxt req is 'a -> ~HttpServletRequest -> 'b = (
        userId = if defined? req#getSession()#getAttribute("user-id") then
                    string req#getSession()#getAttribute("user-id")
                 else
                    "anonymous"
                 fi;
        user = ctxt.userService.loadUser userId;

        scopedCtxt = ctxt with {user = user};
        content = renderPage scopedCtxt;
        {status=200, headers = ["Content-Type":"text/html;charset=UTF-8"], content}
    ),

As always the requestHandler takes a ctxt which contains the dependencies additional it takes a HttpServletRequest argument.

Because the req argument is a Java-Class we have to use the first time a type-annotations (is …). For a description of what type-annotations are, when and how to use them  please read the yeti introduction. But in short they are not only needed when Java-Classes are involved, they are also very handy when you are lost in the types, because than you can annotate functions, variables etc. with types and the compiler checks whether the types you expect match the types the compiler infers.

After the requestHandler has loaded the user of the current session it creates a scopedCtxt.

The scopedCtxt is a copy of the original ctxt enriched with the user. The with keyword means: take the structure on the left, copy it and add to the copy all the fields from the right structure (or replace them if they have the same name).

And this is of course great to create a scoped context for the current request only, which contains exactly the same dependencies as the global context but additional the current user  – without bothering the receiver of the scopedCtxt (renderPage) with what is in which scopes.

Finally we call the renderPage function. This function while it is also a dependency is not injected, because also in practice you of do not inject each dependency especially if you do not have to be super-flexible and for readability prefer a more direct style, or because it is a deep hierarchy where injection would be just to much work and in our example we do not inject the renderPage because we want to demonstrate the flexibility of the context.

    renderPage ctxt = (
       user = ctxt.user;
       productOfDay = ctxt.productService.productOfTheDay user.userId;
       """<html><head></head><body>
           <div id="product">Hi \(user.name), this is nice: \(productOfDay.name)</div>
          </body><html>
       """;
    ),

As you can see we take the user from the scoped ctxt which the requestHandler provides, but the interesting part here is the dependency on the productService.

But the interesting thing here is that the renderPage takes (like always) the productService from the context as a dependency. However without knowledge of the requestHandler or declaration of this dependency in the requestHandler itself, although the requestHandler has alone chosen to use the renderPage function and injects everything needed into this function. But while the dependency of the renderPage is completely transparent to the requestHandler the one who uses the requestHandler must provide this dependency – enforced by the compiler.  And if you would decide that renderPage needs yet another dependency you just take it from the context without modifying the requestHandler at all and the compiler will again enforce that the original ctxt contains this new dependency.

The dependency is passed totally transparently  through the requestHandler and also the other way round: the static type-requirement for the dependency is passed totally transparent to the caller of the requestHandler through the requestHandler

I leave the unit-testing to you and just want to finally plug everything together in a HttpServlet (of course coded in yeti):

productionDAO = {
        readUser name = {userId = name, name = name},
        createUser name uid = {userId = uid, name = name},
        deleteUser name = true,
        readProduct name = {itemNumber = name, name = name}
},

class YetidiServlet extends HttpServlet

    handler = (

        uS = di.userService {userDAO = di.productionDAO};
        pS = di.productService {productDAO = di.productionDAO, userService = uS};
        di.requestHandler {userService = uS, productService = pS, user = {userId = "an", name = "an"}}
    ),

    void doService (HttpServletRequest req, HttpServletResponse res)
         c= handler req;
         res#setStatus(c.status);
         forHash c.headers do key value: res#setHeader(key,value); done;
         wr = res#getWriter();
         wr#print(c.content);
         wr#flush(),

end;

At the end of the blog you can find the full code. I just want to add that – at least I – would have a very hard time to do statically type-checked DI in a possibly hierarchical style with scoped contexts just with the means of the language in as little code with any of the other statically typed JVM languages.

But are there disadvantages in structural typing and if so are they worth it?

Unfortunately yes there are disadvantages:

1. Structural typing is (arguably) more flexible than nominal typing, but this comes at the price that certain mistakes are not caught by the compiler: I.e. if you have a customer structure which you pass mistakenly to a function which expects a supplier which has the same fields (i.e. name, balance) than yeti wont catch that. If you want you can easily prevent this with using Variant Tags (some thing for a later post), but you must do that explicitly while nominative type-systems enforce this always
2. The yeti-type-system adds more limitations to otherwise legal code than more complex type-systems which require type-annotations. I.e. you can not create structures with polymorphic functions through function application. So in our example the productService and userService could not have polymorphic functions. However for “business-service” structures (instead of libraries) you do not that often need polymorphic functions. And if you need them there are ways to work around the limitation (standalone polymorphic functions which take the contexts via a parameter or you could always trick the compiler via casting).
3. Another disadvantage (at least in yeti) is that because the types have no names and are only described by there structure, you often get very long hard to read type-descriptions in compile error-messages.
4. Subtyping  is also better supported in nominal type-systems, but also here Variant (or algebraic data-types) are often the better choice and are supported by yeti. In this context it is also notable, that yeti also supports recursive Structures and Variants without explicit declarations

But IMO all these disadvantages do not justify the more code and lost flexibility you get with the nominal type-systems.

And this seems to be confirmed by the fact that structural typing gets more popular in recent time. Googles Go language supports it, also scala (while it is not the “default”) and the more and more popular functional languages Haskell and ML (the origin of yeti) as well.

The best thing is to try it yourself. Just take a final look at the DI example code and give yeti a try. It is easy to learn, because it is simple and still has very powerful possibilities.

In my experience it is a real pleasure to work with yeti, unmatched by any language on the JVM.

Appendix: The complete sample code

.

module yetidi;

import javax.servlet.http:HttpServletRequest, HttpServletResponse, HttpServlet;

di = {

    userService ctxt = {
        loadUser userId = ctxt.userDAO.readUser userId,
        storeUser user = ctxt.userDAO.createUser user.name user.userId,
        removeUser userId = ctxt.userDAO.deleteUser userId,
    },

    productService ctxt = {
        loadProduct name = ctxt.productDAO.readProduct name,
        productOfTheDay userId = (
            u = ctxt.userService.loadUser userId;
            //choose some product for the user and load it
            loadProduct "itemFor-\(u.name)"
        ),
    },

    dummyDAO = {
        readUser name = {userId = name, name = name},
        createUser name uid = {userId = uid, name = name},
        deleteUser name = true,
        readProduct name = {itemNumber = name, name = name}
    },

    productionDAO = {
        readUser name = {userId = name, name = name},
        createUser name uid = {userId = uid, name = name},
        deleteUser name = true,
        readProduct name = {itemNumber = name, name = name}
    },

    requestHandler ctxt req is 'a -> ~HttpServletRequest -> 'b = (
        userId = if defined? req#getSession()#getAttribute("user-id") then
                    string req#getSession()#getAttribute("user-id")
                 else
                    "anonymous"
                 fi;
        user = ctxt.userService.loadUser userId;

        scopedCtxt = ctxt with {user = user};
        content = renderPage scopedCtxt;
        {status=200, headers = ["Content-Type":"text/html;charset=UTF-8"], content}
    ),

    renderPage ctxt = (
       user = ctxt.user;
       productOfDay = ctxt.productService.productOfTheDay user.userId;
       """<html><head></head><body>
           <div id="product">Hi \(user.name), this is nice: \(productOfDay.name)</div>
          </body><html>
       """;
    ),

};

class YetidiServlet extends HttpServlet

    handler = (

        uS = di.userService {userDAO = di.productionDAO};
        pS = di.productService {productDAO = di.productionDAO, userService = uS};
        di.requestHandler {userService = uS, productService = pS, user = {userId = "an", name = "an"}}
    ),

    void doService (HttpServletRequest req, HttpServletResponse res)
         c= handler req;
         res#setStatus(c.status);
         forHash c.headers do key value: res#setHeader(key,value); done;
         wr = res#getWriter();
         wr#print(c.content);
         wr#flush(),
end;

di;

Yeti has editor-support for vim, notedpad++ (windows) and Netbeans. It is very limited - basically syntax higlighting and brace matching etc.

Still try it out.

All of them take you a minute to install. None of them is buggy (because they are simple).  And eyes just like colors.

I’ll shortly describe each of them below. If you are in a hurry skip the next paragraph.

A few Words on IDE Support in General

I think if you chose/try a a new language you should really see how it does with a simple plain editor, because in programming the language is the cook and the IDE is the waiter when you are the restaurant owner.

The best IDE with code-completition, -analysis, refactoring, generation what so ever can only go so far as  the language lets it and has to go so far because the language needs it.

And for that reason none of the most popular languages today started out with excellent IDE support. In contrary most of the time the falling languages have had the best IDE support because IDEs have to make good what the languages do not support but newer competing languages do.

This does of course not mean that IDE support is useless – of course it would also be very nice if  Yeti had Java-quality IDE support. However it is no way as important for Yeti as ie for Java for different reasons:

• Yeti code is compact so you do not type that much especially foreign defined identifiers like classnames for typing where ie code-completetion helps a lot
• For the same reason you do not have to read that much and an outline-few is not such a must.
• There are also not huge apis with hundreds of classes each having in turn tenth of  (partly inherited) methods so again code-completetion documentation-popup etc is not that important.
• The yeti-compiler is very fast and with the continues compilation possibility shown in the last post you do have very short edit/run/test cycles, which makes error-higlightning less important

Enough said here are the supported Editors/IDEs.

Vim

Vim support comes form the creator of Yeti Madis himself. You find the syntax and filetype plugin at the home page of yeti http://mth.github.com/yeti/.

To install the plugin follow this quotation from the Yeti homepage:

Vim syntax hilighting and filetype plugin.
Save these files as ~/.vim/syntax/yeti.vim and ~/.vim/ftplugin/yeti.vim accordingly, and add
au BufNewFile,BufRead *.yeti setlocal filetype=yeti ts=8 sw=4 sts=4 expandtab
into your ~/.vimrc.

Notepad++

Notepad++ is one of the most popular Editors for Windows.

You can download  a “user defined language” file for Yeti :  http://chrisichris.github.com/chrisis-maven-repo/notepadplusplus_yeti.xml (right-click the link to save the file).

To install:  download the above file, open Notepad++  go to  ”View > User-Defined Dialogue…” press the button “Import…”.  and open the file. Done.

Note: The “Import..” function is only supported in current versions. If your Version does not support it either upgrade (which you should anyway) or Google on how to install user defined language files in older Versions its not that much more work.

Netbeans

You can also find a basic Netbeans plugin for Netbeans 6.8 and 6.9 here: https://github.com/chrisichris/nbyeti

You can download the module (org.nbyeti-6-8-01.nbm) file from the downloads section of the above github page.

You install it like any other Netbeans-module you have downloaded – nothing special there. See the the link above for detailed installation instructions.

If you are choosing Netbeans for your Yeti-devolopment I recommend you to also use the maven-netbeans-plugin and than create a maven yeti project as described in my last blog-post. This way you have a full integrated yeti/java netbeans project within a few minutes.

I hope that helps a bit.

If you have any questions use the yeti mailing-list: http://groups.google.com/group/yeti-lang . See you there.

One way to run Yeti-Code is to use the yeti.jar directly. This is very well described in the yeti tutorial http://linux.ee/~mzz/yeti/intro.html.

In this post I want to show you how to use the yeti-maven-plugin https://github.com/chrisichris/yeti-maven-plugin

Advantages of using the yeti-maven-plugin

When you hear maven-plugin do not shy away it is not more work than using the yeti.jar directly, contrary it gives you a few advantages:

• It  is easier to manage the classpath especially using jars both for running with the REPL and compiling
• It is a standard way to compile and test, distribute etc your yeti-code and integrates well if you want to also code parts in Java (or other JVM- languages)
• yetidoc can be produced
• a mavenproject is understood by all ides. A pure YETI-project as above not

Starting a Yeti Maven project and basic Usage

To start a maven-yeti-project you have to

1. Install maven 2 or greater (If you are a Java-Programmer you very propably have that already) http://maven.apache.org/run-maven/index.html
2. Download the yeti-project-template.zip file from the downloads section of the yeti-maven-plugin https://github.com/chrisichris/yeti-maven-plugin
3. Unpack the file in a directory of your choice and name it as you project.
4. Change in the pom.xml file the contents of the groupId, artifactId and name tags to your projects name
   

       <groupId>your.groupId</groupId>
       <artifactId>your-artifactId</artifactId>
       <packaging>jar</packaging>
       <version>1.0-SNAPSHOT</version>
       <name>your projects name</name>
                

Now your maven project is setup and read to use.

You can put your yeti module files in the src/main/yeti directory or side-by-beside with your java files in src/main/java – for test files the corresponding src/test directories are used.

You can use all the mvn commands ie mvn compile mvn test mvn install In all these commands the yeti sources get compiled, tested, jared up etc exactly like the Java sources.

And you can start the interactive REPL:

mvn -Dyeti-compile=false clean compile yeti:repl

This will first clean than compile the Java sources and start the REPL with the full project classpath (including test-classes dependencies etc). The yeti sources are not compiled in this case (-Dyeti-compile=false), because the REPL will pick up the sources itself directly and compile them.

Interactive Development with the REPL

Yeti is new so Yeti does not yet have the IDE support Java has.

Among other things that means that when you code Yeti the IDE does not show you instantly compile errors you might have made. Instead you always have to edit your file, save it go to the command prompt, call compile (or reload the module in the repl), see a compile-error, fix it and start all over again. That’s boring lost time.

The yeti-maven-plugins REPL helps here.

In the repl you can define arbitrary yeti-code which gets executed each time you change sources.

You can use this facility to execute load module.name commands each time you save your changed code. This way the REPL will (re)compile the module immidiately in the console, and you do not have to repeat the above circle.

Try it out: create a yeti module: src/yeti/example/immediateCompile.yeti (if you have started the project from the yeti-project-template.zip file – as described above – this file is already present)

module example.immediateCompile;
"just an example showing the immediate compile function of the repl";

From the shell start the REPL and in the REPL add a monitor which will load the immediateCompile module whenever the a source-file is changed.

mvn -Dyeti-compile=false clean compile yeti:repl
....
Ready to take your commands :)
yeti>-s.addMonitor "recompile monitor" \(s.branche "load example.immediateCompile");
<p>shell:added monitor 1: recompile monitor: <code$>
yeti>
...

And now just modify in you editor the code of your module. Save it and see the compiliation output.

Ie introduce a bug:

module example.immediateCompile;

this is a bug

"just an example showing the immediate compile function of the repl";

Save the file and you should (quite) immidiately see the compiler result on the repl.

yeti>
yeti>monitor:
yeti>-----------------------
branche start: load example.immediateCompile
yeti>load example.immediateCompile
example/immediateCompile.yeti:3:1: Unknown identifier: this
branche end: load example.immediateCompile
------------------------
yeti>

In the repl you see that the code load example.immediateResult is executed and that the compiler showed the error: example/immediateCompile.yeti:3:1: Unknown identifier: this.

Correct the bug in your source file.

module example.immediateCompile;

"this is no bug anymore"

Save it and you get automatically on the repl

------------------------
yeti>monitor:
yeti>-----------------------
branche start: load example.immediateCompile
yeti>load example.immediateCompile
"this is no bug anymore" is string
branche end: load example.immediateCompile
------------------------

The module was compiled, executed and returned "this is no bug anymore" is string. So everything works fine.

Using the REPL to run Continously rudimentary Tests

As we saw the monitor we added to load the module did not only compile the module it actually compiles and runs it too.

This can be of course used to also test modules as soon as you change them.

To do so instead of loading the main-source module you define a test module under src/test/yeti which in turn loads the main module and checks its result.

Lets do that:

Create a file src/test/yeti/example/testImmediateCompile.yeti:

module example.testImmediateCompile;

t = load example.immediateCompile;

if t != "this is no bug anymore" then failWith "wrong result \(t)" fi;

"test immediateResult was ok"

This module first loads the example.immediateCompile module than checks the returned string. If it does not fit it fails with an exception. Otherwise it finishes normally confirming that the module under test is ok.

Before we add a monitor for the new test module, we turn off the old monitor, using -s.showMonitors() to find its id and than calling -s.removeMonitor id to remove it.

Than we add the new monitor:

yeti>-s.showMonitors()
shell:monitors:
1: true: recompile: <code$>

yeti>-s.removeMonitor 1
shell:removed monitor 1
yeti>
yeti>-s.addMonitor "testImmediateCompile" \(s.branche "load example.testImmediateCompile");

And now the module is not only recompiled each time you change and save it but also tested – very similar as in dynamic languages and even better than what the very advanced Java-IDEs provide.

This is of course no nice test-framework. A way to test yeti properly will be handled in a next blog-post.

But for having fun with Yeti it is a good start.

And if you are not board don’t forget to read the readme for the yeti-maven-plugin it has a few additional infos https://github.com/chrisichris/yeti-maven-plugin

And than about a year ago I found by chance a link to yeti: http://linux.ee/~mzz/yeti/intro.html Which was for me exactly the right mixture:

Yeti

• is a very simple yet powerful functional language
• is staticly typed with full typeinference and with as little type-typing you can get – if you want so none like in a dynamic languge
• runs on the JVM and integrates with java

Yeti is simple yet powerful

In Yeti you have to know basicly 4 things:

• functions: because all code is in functions and invokes functions (there are no classes or objects)
• values: 3 base types (number, string, unit ) and the composed types (list, array, hash, structure) and their literals ie ["one","two",three"] for a string list
• how to assign the values to mutable and immutable variables
• the if-expression and the case expression

If you want to learn the whole language then read the intro http://linux.ee/~mzz/yeti/intro.html Thats one document in a tutorial style which takes you about 2 hours to read and than you know 98 % of the language.

Yeti is also quite pragmatic it is not haskell strict immutable and you can typecast values work with objects etc.

Still yeti is powerful. Like in any functional language you can code in a very elegant concise way things which take much more LOC in a OO language.

Again please take a look at the tutorial I leave here the prove for later posts.

Yeti has a simple but powerful type-system with full typeinference

Any typesystem is a compromise: Either it is powerful and complicated and therefore can check a lot of different code or it is more simple and forbidds certain code which is otherwise perfectly legal. It is ongoing scientific process to find here a good balance.

However for many and for a long time now the ML typesystem und its typeinference alogartihmus is seen as a sweetspot in this compromise.

Yeti implements excatly this sweetspot-typesystem (with a few additions). To my knowledge no other VM-language does this.

The typesystem supports polymorphism (similar to Java Generics), mutable values and arrays with full type-inference.

As long as you don’t use legacy Java code you do not have to write any type in yeti – everything is inferred (you can if you want specify types on function etc for debugging – but you don’t have to).

In yeti you also do not define types. There are no classes, interfaces, traits etc. Yeti is purely structural typed. Every type is composed of the above mentioned basic types. The compiler inferece from your useage of values what you want and checks wheter you provide the right thing.

If your functions needs a structure with a field “swim” holding a function than the compiler checks wheter your code provides a structure with the field “swim” holding a function but it does not demand that you declare and instantiate a class “Duck” “Boat” or what soever etc.

So yeti is very very close to the “agile” dynamic languages, because it behaves like them in many respects (no typeannotations no typedelcarations no type instantiation) but it still checks the types, which saves a lot of test-code maintance and reading.

To my knowledge no other JVM language combines agility with static typechecking as close as Yeti.

What is not so good with yeti?

In my opinion the two main disadvantes are:

Yeti does not integrate as nicely with Java as Scala. But Java integration works both ways and with little problems. You just have to do a bit more work with types

Yeti does not have a big community. I thinkt thats its main problem

Where to continue?

Downlaod yeti http://mth.github.com/yeti/ read the tutorial http://linux.ee/~mzz/yeti/intro.html and have fun with the repl.