Constructor Patterns

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

def myobj = object def destruct_ Boom = 1 end

#assert 
  match myobj
    case Boom x => false
    case Boom ! x => x == 1
  end

#assert
 match Boom 1
   case Boom x => x == 1
   case Boom ! x => false
 end 

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.

Programming and Scaling

Interesting talk by Alan Kay, the inventor of the term “object-oriented”: Programming and Scaling.

Midnight in Paris

I don’t understand, what’s holding them in the room?

You gotta love Woody Allen’s newest creation, for little fun moments like above reference to “The Exterminating Angel”, and for pointing out obvious, but easily forgotten truths. If you haven’t already, it will also make you fall in love with Paris. Makes me want to jump right into the train from Saarbrücken to Paris.

Grid Systems

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?

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!

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

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) = 
    object
      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
    end
  
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:
  begin
    u.(2) = 18
  end

#catch 2 try:
  begin
    u.(exception 2) = 18
  end
  
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


end

Barney’s Version

The story is interesting (finally I learnt what to do with onions before cutting them) but the true brilliance of this movie lies in its phenomenal cast.

Aiming for the bushes

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

Babel-17 can call Java now

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 _ = 
  begin
    ar.add 1
    ar.add 10
    ar.add 5
    ar.add s
    ar.add ((18, 13, 15),)
  end
ar.toArray ()

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