Archive for the ‘Babel-17’ Category

Constructor Patterns

August 22, 2011

Currently (Babel-17 v0.3.2), how destructing works is not really what I intended initially:

def myobj = object def destruct_ Boom = 1 end

  match myobj
    case Boom x => false
    case Boom ! x => x == 1

 match Boom 1
   case Boom x => x == 1
   case Boom ! x => false

Both assertions currently hold. This is because the pattern Boom x only matches a true cexpr, but not a value that just responds to the destruct_ message.

The thing is that initially I introduced constructors just so that effortless pattern matching is possible against objects that are NOT of type cexpr, but choose to behave as such. Therefore the pattern C pat where C is a constructor should really mean the same as C ! pat. There is only one problem with that:

typedef suit Hearts, Diamonds, Spades, Clubs

This currently is short for

typedef suit (x as Hearts) = x
typedef suit (x as Diamonds) = x
typedef suit (x as Spades) = x
typedef suit (x as Clubs) = x

Now, if I do the following:

def myobj = object def destruct_ Hearts = nil def hello = "Hello there!" end
val strangeSuit = suit myobj 

Now strangeSuit is of type suit, but also responds to the hello message. That surely wasn’t intended.

The solution is to define the meaning of the suit type definition
to be:

typedef suit Hearts = Hearts
typedef suit Diamonds = Diamonds
typedef suit Spades = Spades
typedef suit Clubs = Clubs

Then everything works fine and the encapsulation of the suit type is guaranteed.

Grid Systems

July 22, 2011

I found a terrific read: Ordering Disorder: Grid Principles for Web Design by Khoi Vinh, former Design Director of the NYTimes, is exactly the book I was looking for to learn in depth about grid systems in UI design. I hope to be able to transfer some of my new found wisdom to the design of the Babel-17 UI support.

How productive can a single programmer be?

July 21, 2011

Here are the things I’d like to get done in the next 3 months:

  • Babel-17 running on GAE
  • A user interface concept for Babel-17 relying on constraints, grid systems, and modern design principles. Can’t wait to get my fingers on the upcoming Design for Hackers.
  • A first version of one of my projects (like Applied Cuisine) running on Babel-17
  • A compiler from Babel-17 to Java
  • A compiler from Babel-17 to Objective-C
  • A compiler from Babel-17 to Javascript

It always helps to look back at a comparable time frame and what has been achieved then in it. So lets do that and immediately cross off the last three items from that list 🙂 Can the rest be done in three months time? We will see.

Babel-17 v0.3.1 is out!

July 20, 2011

I have put together the two new big features of Babel-17, support for lenses, and Java interoperability, to form the backbone of this new release. The specification has been cleaned up and improved in a couple of places. Download Babel-17 v0.3.1 now!

Lenses in Babel-17

July 19, 2011

Google App Engine (GAE) uses a document centric database model (Big Table). Therefore, before digging into the details of how to integrate it with Babel-17, I decided first to implement lenses for Babel-17. A complete implementation is checked into the repository, and it will come out as part of Babel-17 v3.1 . I am pretty excited about applying it to GAE and the standard library of Babel-17.

So a lens in Babel-17 is a value of type lens_, and there is a new keyword lens which is used to create lenses from scratch. The old record update syntax has become part of how lenses work. I will update the Babel-17 spec within the next few days, for now to get a sneak preview of how lenses in Babel-17 work, check out this unit test module for lenses:

module lang.unittest.spec.lenses

val u = {a = 1, b = {i = 2, j = 3}}
val v = u

val l = lens x => x.b.i

#assert l u == u.(l) == 2

#assert typeof l == (: lens_)

u.(l) = 5

#assert u == {a = 1, b = {i = 5, j = 3}}
#assert v == {a = 1, b = {i = 2, j = 3}}

v.b.j = 42
v.(l) = 6
v.a = v.a + 10

#assert v == {a = 11, b = {i = 6, j = 42}}

v.b.j = v.b.i
v.b.i ^= 2
v.b.j =^ 2

#assert v.b == { i = 6^2, j = 2^6 }

l = lens x => x

v.(l) = 77

#assert v == 77

typedef mymap (c : map) = 
      def lookup k = c k
      def lookup_putback_ k = x => mymap (c + (k, x))
      def get k = if c.containsKey(k) then Some (c k) else None end
      def get_putback_ k = 
        (case Some x => mymap (c + (k, x))
         case None => mymap (c - k))
      def this:map = c
val c = { 1 -> 2, 2 -> 3, 3 -> 4, 4 -> 1 }
val m = mymap c

#assert m.get 3 == Some 4

m.get 3 = Some 10

#assert m == {1 -> 2, 2 -> 3, 3 -> 10, 4 -> 1}

m.get 3 = None

#assert m == {1 -> 2, 2 -> 3, 4 -> 1}

#catch DomainError try: m.lookup 10
m.lookup 10 = 24
#assert m.lookup 10 == 24

val f = lens x => x.b
val g = lens x => x.i      

u.(f*g) = 13

#assert u.b.i == 13
#assert u.(f*g) == 13

val h = lens x => x.(f).(g)

#assert u.(h) == 13

u.(h) = 79

#assert u.b.i == 79

u.(f).(g) = 80

#assert u.b.i == 80

#catch ApplyError try: u.(2)

#catch DomainError try:
    u.(2) = 18

#catch 2 try:
    u.(exception 2) = 18
val fst = lens ((x, y) => x, (x, y) => z => (z, y))
val snd = lens ((x, y) => y, (x, y) => z => (x, z))

val x = (1, 2)

x.(fst) = 10

#assert x == (10, 2)

x.(snd) = 13

#assert x == (10, 13)

val x = 10
x += 2
#assert x == 12

x div= 2
#assert x == 6

x =div 18
#assert x == 3

val x = true

x xor= true

#assert not x


Aiming for the bushes

July 13, 2011

This is by far the funniest I have watched recently (in the last 5 years).

Babel-17 can call Java now

July 12, 2011

I have done some serious thinking about how to use Babel-17 to power my projects like Applied Cuisine.

The main backend for my projects is going to be Google App Engine (GAE). So it would be great if I could use Babel-17 for GAE development. The first step to achieve this has been done now. Babel-17 can call Java now. Here is an example:

val s = native New ("java.lang.Short", 2)
val ar = native New ("java.util.ArrayList")
val _ = 
    ar.add 1
    ar.add 10
    ar.add 5
    ar.add s
    ar.add ((18, 13, 15),)
ar.toArray ()

The above code evaluates to (1,10,5,2,(18,13,15)).

Babel-17 v0.3 is out !

June 30, 2011

Check it out now at

Automatic Type Conversions

June 29, 2011

Writing unit tests is a great thing. It makes you think even harder than usually about the semantics of your code.

In Babel-17 you have real interval arithmetic; for example, to describe the interval between 4 and 5, you could write [4.0; 5.0]. This notation, [a;b] assumes that a and b are reals, and forms the convex hull that contains both a and b.

Now. Should it be possible to also write [4; 5] for the above interval?

In my current preliminary spec for Babel-17 v0.3 the answer is NO. An integer is not a real; for example you cannot compare them, 2 == 2.0 evaluates to false. This point of view has a lot going for it; it seems pure.

(Un)fortunately, people don’t care so much about purity. I can already see the looks on faces when I try to explain that [4.0; 5.0] is a real interval, but [4; 5] is not even a legal expression.

There is an obvious solution to this dilemma: type conversions. These are already a part of Babel-17 v0.3: for example, 3 :> real converts the integer 3 to the real 3.0 .

Type conversions could be used such that whenever I need in a particular situation a value of a certain type T, I check if my value at hand can be converted into something of type T. If yes, I use the converted value instead, if not, then it’s a DomainError.

For this not to result in total chaos, a necessary condition for a type conversion to succeed should be that the conversion is reversible (at least in principle). Note that this is only a necessary condition, and you should really think twice before providing a type conversion. Often it makes more sense not to provide a type conversion, but just a conversion function which has to be invoked explicitly.

As an example, look at the conversion between integers and reals. It should be possible to convert integers that are not too large to a real; but if the integer is too large to be represented faithfully as a real number, the conversion should fail. Likewise, a real r for which r.round == r holds should be convertible to an integer. But the conversion should fail for those r with not(r.round == r).

This is a big issue, and adding automatic type conversions to Babel-17 changes the whole look and feel of the language. It will make it a lot easier for beginners to get friendly with the language; at the same time it will make it harder for a compiler (but not impossible, especially for a JIT) to generate fast code.

Automatic type conversions will be introduced in the upcoming Babel-17 v0.3, and further developed in Babel-17 v0.3.1.

Feature Complete

June 28, 2011

Babel-17 v0.3 is feature complete! Everything has been implemented, and there is also a new version of the Babel-17 plugin for Netbeans 7.0. The two biggest changes in the plugin are:

  • there are Babel-17 projects now
  • there is support for running unit tests

Tuesday is dedicated to going through the specification and writing unit tests that check the spec. Hopefully only minor fixes will be necessary; if so, then Tuesday night Babel-17 v0.3 will be released!