Summary
Wherein I talk about the merits of type inference, the latest Cat release, unit tests, and miniature computers.

---

Advertisement

I just posted a considerably more stable version of Cat (version 0.7.1) online at http://www.cat-language.com which has a working type inference engine for both stacks (previously it only sort-of worked for trivial expressions on a single stack).

I have been retroactively adding unit tests. (I can already hear Michael Feathers saying "You should have been writing the tests first!"). While I am a proponent of test driven development (TDD) in theory, to be completely candid I didn't actually practice it. Now that I am developing in C#, I find it easier for some reason (perhaps less fear of writing in an OOP style ... the C++ community frowns on OO style code for some reason?!). Writing a type inference engine is of sufficient complexity that I found that I I didn't have much choice: write unit tests or give up. Adding unit tests even this late in the game was still a great idea! I managed to work out a lot of kinks very quickly (much more so than external test suites). It also has been forcing me to remove unneccessary coupling in the code base.

Not many languages support type inference, but it is very useful. In fact it is indispensible in to have type inference in a language like Cat which has a strong type system. In Cat there are two stacks, and every operation is a transition from these two stacks to two other stacks. As a result type notation looks like:

define add_and_load : (int int)()->()(int) { add_int load }

Clearly it is a bit silly if your language requires more complexity to express types than the actual code! Now in Cat you can write:

define add_and_load { add_int load } 

and the interpreter will figure out the type for you. You can ask for the type explicitly using:

@add_and_load type_of

This is in fact only the tip of the iceberg. Cat types can quickly get quite very sophisticated because it supports polymorphism (the C++ kind, not the ML kind ... what is it called universal quantification or something?).

The type of the Cat if operation is rather involved:

define if : (bool (A)->(B) (A:any*)->(B:any*))->(B)

Here is what this means in English: the if operation requires two functions of the same type on the top of the stack, and below that a boolean value. If the value is false, then the first function popped off the stack is executed, otherwise the other one is executed.

So this might seem like nothing fancy on the surface but consider the following: the MSIL (Microsoft Intermediate Language) byte-code has a similar restriction on "if" assembly code instructions. It is just that in Cat this is expressed naturally using a type-system.

This is almost precisely why I invented Cat: it maps to and from assembly code and while maintaining a strong type system. It also cleanly maps to and from other imperative languages (like Heron ... see where I am going with this?). Of course Cat can do a lot of things most assembly code can only dream of.

I have a lot of possible applications in mind for Cat, and something while pulls at my heart is as a language for developing applications on the latest generation of miniature and cheap computers (http://linuxdevices.com/news/NS6828123924.html and http://laptop.org/).

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Christopher Diggins adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.