<< Previous | Next >>

Hotel at day 365 minus 1 week; A Year of Hotel

To be fair, after the last hotel blog post in October, not much has happend. The status than was a c implemented parser, emitting a total of 50 different bytecodes, and a runtime that was somewhat functional. However, it didn't seem like I was going to reach the goal of simplicity.

Development on attempt 1 stalled, and died. (Also because my day job became very demanding; we are working on something new and cool. More on that in the near future.)

But hotel didn't die, I was, and still am, very much thinking about it. Inspired by some papers and other sources, I implemented a simple vm in python, just 3 different instructions, and a nano pass framework. Later I redid that in javascript, with some twists and a primitive parser.

But now a very serious attempt is in Java. I have the same nano pass architecture. I have the same 3 basic bytecode instructions plus literals. I have a parser generator and a proper grammar, allowing me to grow the language much faster (syntax wise). I have a runtime that is (explicitly) a bit naive, but nice and simple, very suited as a reference implementation. It is growing nicely, and hotel is now much further along than it has ever been.

Two Thoughts

From day one of hotel, I could never decide between mutable data, or not; a functional language, or a imperative language. Attempt 1 clearly went for mutable data ... surprise! ... attempt 2 is an eager, dynamically typed, functional programming language. That is, no mutation of data, eager evaluation and functions (and scopes) as first class citizens.

Still same thoughts on scopes, namespaces and such. This is how hotel looks right now (and this code fully works):

Point = fun :x :y (
  area = fun x * y
  self
)
p = Point 10 20
print p.area
;; outputs 200 when run

Being a functional language, you don't need variable declaration to establish scope: assignent is declaration (otherwise you would have mutation). Unchanged is the implicit return of the last evaluated statement. self still refers to the local scope as a full object, with the local variables as its fields (including the function arguments when appropriate).

Regular braces group code, including function bodies, so no curly braces required. Everything is a function call, even when no arguments are given. This is great for field getters. (Setters are not required, since there is no mutation.)

Translated to regular java, the print p.area statement reads: print( p("area")() );. Two noticeable things: one, field access is a regular function call with one argument (a symbol); two, the result is actually executed.

In essence: values (non functions) when called with zero arguments, return themselves. When called with one argument, return the denoted field or undefined. This blurs objects and functions together in a well defined protocol.

Well, that is enough for today. Lets hope attempt 2 makes it out the door.

Last modified: 2008-09-02 21:36 GMT