It's alive
(Warning: This post is not going to be interesting to anybody who is not a computer science major or a computer programmer.)
As I am anxiously waiting for the corrections from the proofreader, I have already started planning what my next book should be all about. Before launching the word processor and writing the first sentence, I thought that I might post here a few words about the programming language Zilk that I designed and implemented on a total whim last year. I got an inspiration for it while I was casually browsing a programming book by Herbert Schildt, because one example in it was a compiler and interpreter for a small programming language. It looked like a fun project, and I since had never actually written a compiler before (of course, I was familiar with the overall general theory), I thought that I'd take a shot and write a little language perhaps in style of Basic of Commodore 64.
At least that's what I'd thought to do, but the project then snowballed quite a lot. As you can see from the documentation, the language is very much like Python and Ruby, perhaps leaning closer to the latter. At the moment, the language is already well at the complexity level of these two famous languages. Zilk is very dynamic and has static typing, which makes it quite flexible when combined to the fact that just like in Ruby, every statement is an expression and every class, lambda expression and everything else is an object. For example, you can take a method from an object aside as a method object, pass it around, and then call it later like any other function, and it magically works on the original object. The language is in fact so dynamic that when you define a class by extending another class, the superclass does not have to be named or known at the compile time but can be evaluated dynamically like any other expression. I don't think that even Ruby is this dynamic at the moment.
Zilk is syntactically very liberal so that it is insensitive to whitespace, and when you define lists, you don't need to use commas to separate the elements. Statements don't have be separated with semicolons, since the compiler already knows where a statement ends. (You can use separator commas and semicolons, if you want to, though.) In a conditional statement, the condition doesn't need to be separated or parenthesized, but of course this is allowed. When I was developing the syntax of Zilk, I "fixed" certain things that annoyed me in other languages, including Ruby and Python, although I did take in a lot of great syntax especially from Ruby. For example, using curly braces to delimit lambda blocks, using
One thing that has always annoyed me is using
As I wrote and designed Zilk, I learned a lot about various topics that I didn't even have any idea of at the time when I started the project. For example, it was a humongous effort to make the keyword
In the beginning of the project, the compiler and interpreter that were written in Java were "real" in my mind so that I was thorougly familiar with their details and behaviour and knew what exactly was going on at any given time, and the Zilk language was vague, magical and ephemeral, a ghostly side effect of executing this Java code that I knew and understood well. However, as the language became more solid so that it was possible to write more complex things and even use Zilk to implement parts of it instead of writing these parts in the underlying compiler and interpreter, gradually Zilk became "real" in my mind whereas the underlying compiler and interpreter became vague and magical! I could just do my thinking and working in Zilk and it just magically worked. I then started to remove things that I had implemented in the language itself and lifted them to one level of abstraction higher, rewriting them using the rest of Zilk. For example, I put a lot of stuff in a file std.zil that gets executed before the actual user program and defines all kinds of constants and functionality: for example, various iterator and filtering methods,
The nice thing about Zilk is that since it was written in Java and the interpreter runs on top of Java, you can take any Java class and use it in Zilk. The Zilk interpreter invisibly puts the necessary wrapping around the Java class so that it works like a normal Zilk class. A Java class can even be used as a superclass to create a Zilk class. This way, I don't need to reinvent the wheel since e.g. the GUI classes of Java can be used to create a user interface for a Zilk program. As a small demonstration, I wrote a simple minesweeper game mines.zil with Zilk. The only problem in using Java classes from Zilk is that since Zilk is dynamic and untyped whereas Java is statically typed and type-checked, it is not possible to write a Zilk class that actually "implements" a given Java interface, so we have to go around this with some hackery and trickery.
Even better, it was trivial to write a small Java applet class that launches and executes a given Zilk program. This way, Java applets can be written with Zilk and distributed and run over the Internet in any machine that can run Java applets. For example, the small demonstration program mines.zil can be run as an applet on this page. As an added touch, a Zilk program knows if it is running as an applet, in which case trying to read a file results in downloading that file from where the applet came from, instead of trying to read the file in the local filesystem and failing with a security violation.
I haven't touched the project since May 2005, other than writing material about it to the book that I am currently finishing. The language and the important parts of the implementation of its compiler and interpreter comprise about a third of the book. In this limited space, I can only go through the most important and illustrative parts, of course, with the idea that after understanding them, the rest should be easy to understand and occasionally even self-evidently obvious without my explanations.
As I am anxiously waiting for the corrections from the proofreader, I have already started planning what my next book should be all about. Before launching the word processor and writing the first sentence, I thought that I might post here a few words about the programming language Zilk that I designed and implemented on a total whim last year. I got an inspiration for it while I was casually browsing a programming book by Herbert Schildt, because one example in it was a compiler and interpreter for a small programming language. It looked like a fun project, and I since had never actually written a compiler before (of course, I was familiar with the overall general theory), I thought that I'd take a shot and write a little language perhaps in style of Basic of Commodore 64.
At least that's what I'd thought to do, but the project then snowballed quite a lot. As you can see from the documentation, the language is very much like Python and Ruby, perhaps leaning closer to the latter. At the moment, the language is already well at the complexity level of these two famous languages. Zilk is very dynamic and has static typing, which makes it quite flexible when combined to the fact that just like in Ruby, every statement is an expression and every class, lambda expression and everything else is an object. For example, you can take a method from an object aside as a method object, pass it around, and then call it later like any other function, and it magically works on the original object. The language is in fact so dynamic that when you define a class by extending another class, the superclass does not have to be named or known at the compile time but can be evaluated dynamically like any other expression. I don't think that even Ruby is this dynamic at the moment.
Zilk is syntactically very liberal so that it is insensitive to whitespace, and when you define lists, you don't need to use commas to separate the elements. Statements don't have be separated with semicolons, since the compiler already knows where a statement ends. (You can use separator commas and semicolons, if you want to, though.) In a conditional statement, the condition doesn't need to be separated or parenthesized, but of course this is allowed. When I was developing the syntax of Zilk, I "fixed" certain things that annoyed me in other languages, including Ruby and Python, although I did take in a lot of great syntax especially from Ruby. For example, using curly braces to delimit lambda blocks, using
@ and @@
to indicate class fields and class variables, and using vertical bars
to delimit the list of arguments not just in lambda blocks but also in
named functions and methods. I wish other languages used these same
excellent conventions.One thing that has always annoyed me is using
=
to indicate assignment, since in every other walk of life this operator
means equality testing, so in programming we have to make up idiotic
operators such as == for equality testing. In Zilk, there are keywords is for assignment and eq for equality testing.As I wrote and designed Zilk, I learned a lot about various topics that I didn't even have any idea of at the time when I started the project. For example, it was a humongous effort to make the keyword
super
(for calling the superclass method) work correctly so that it works in
a static fashion even in inherited methods and dynamic contexts. But I
finally somehow managed to do this. I also learned many other things
that then clarified me certain aspects of Python and Java. If I had
known in the beginning how far this project reached, I would have
designed many things differently. But every step was extremely
educational. Hunting and fixing bugs in the language was also an
enormous effort.In the beginning of the project, the compiler and interpreter that were written in Java were "real" in my mind so that I was thorougly familiar with their details and behaviour and knew what exactly was going on at any given time, and the Zilk language was vague, magical and ephemeral, a ghostly side effect of executing this Java code that I knew and understood well. However, as the language became more solid so that it was possible to write more complex things and even use Zilk to implement parts of it instead of writing these parts in the underlying compiler and interpreter, gradually Zilk became "real" in my mind whereas the underlying compiler and interpreter became vague and magical! I could just do my thinking and working in Zilk and it just magically worked. I then started to remove things that I had implemented in the language itself and lifted them to one level of abstraction higher, rewriting them using the rest of Zilk. For example, I put a lot of stuff in a file std.zil that gets executed before the actual user program and defines all kinds of constants and functionality: for example, various iterator and filtering methods,
call, delegates etc.The nice thing about Zilk is that since it was written in Java and the interpreter runs on top of Java, you can take any Java class and use it in Zilk. The Zilk interpreter invisibly puts the necessary wrapping around the Java class so that it works like a normal Zilk class. A Java class can even be used as a superclass to create a Zilk class. This way, I don't need to reinvent the wheel since e.g. the GUI classes of Java can be used to create a user interface for a Zilk program. As a small demonstration, I wrote a simple minesweeper game mines.zil with Zilk. The only problem in using Java classes from Zilk is that since Zilk is dynamic and untyped whereas Java is statically typed and type-checked, it is not possible to write a Zilk class that actually "implements" a given Java interface, so we have to go around this with some hackery and trickery.
Even better, it was trivial to write a small Java applet class that launches and executes a given Zilk program. This way, Java applets can be written with Zilk and distributed and run over the Internet in any machine that can run Java applets. For example, the small demonstration program mines.zil can be run as an applet on this page. As an added touch, a Zilk program knows if it is running as an applet, in which case trying to read a file results in downloading that file from where the applet came from, instead of trying to read the file in the local filesystem and failing with a security violation.
I haven't touched the project since May 2005, other than writing material about it to the book that I am currently finishing. The language and the important parts of the implementation of its compiler and interpreter comprise about a third of the book. In this limited space, I can only go through the most important and illustrative parts, of course, with the idea that after understanding them, the rest should be easy to understand and occasionally even self-evidently obvious without my explanations.
Comments