Lua's syntax

In search of inspiration for language syntax style I remembered Lua. It takes the third major path apart from curly braces (C) and off-side rule (Python). It is thus reminiscent of the Algol family, especially Ada, UNIX shell syntax or Karel (at least some incarnations thereof).

Lua is (mostly) free-form and uses what I call in my head (inappropriately, perhaps) implicit block delimiters. Where a declaration of some program element in C might look like

declaration {
        element;
        element;
        ...
}

in Lua it is instead

declaration
        element;
        element;
        ...
end

What I like about the latter case is that programmer is freed of the choice whether or not to use curly braces to delimit a single statement in control flow expressions such as if, for, while. Still, the language remains free-form and the code looks visually balanced to my eyes. For some reason I feel the cosmic balance disturbed if the beginning end end statement are not both marked, with the same indentation. In Python the blocks feel– incomplete– without the final delimiter. Of course, which style has better signal-to-noise ratio, can be disputed.

Here, Lua is somewhat more concise than Ada or Fortran where we annotate what kind of block we are ending (e.g. if ... then ... else ... end if) in hope of helping the programmer match the delimiters more easily (and to help the compiler spot bracketing errors).

One design element of Lua syntax that I don't really like is the freedom to or not to terminate any statement with a semicolon. Instead a statement can be terminated with a newline. On one hand this allows us to avoid using punctuation unless necessary, on the other hand the language is not fully free-form. Quoting from the reference manual, the code

a = f
(g).x(a)

would be mistaken for two statements. Gorgeous ^_^.

In Ada all statements (and other program elements) are terminated with a semicolon. The Prosody IM software written in Lua seems to have adopted a coding style where every simple statement is terminated with a semicolon, while any compound statement or element ending with the end keyword is not.

Conclusion: While Lua syntax style need not be perfect, it demonstrates that even this syntactic style does not have to be excessively verbose. I like it enough to consider its style as a primary source of inspiration.

Note: When will I actually post anything related to HelenOS?

The woes of C II: Attack of the Teenade Mutant Cabbage

Anyway, I can hardly imagine a supercalifragilisticexpialidocious operating system such as HelenOS can be 0.70710678118654757 as supercalifragilisticexpialidocious if it is written in C. Rather than using an existing programming language which is not s32s enough, I'd much rather design my own programming language.

There are two cons: (1) bigger adoption barrier, (2) designing a language and writing the compiler is not a small job. (As a starting point for an estimate, the C compiler I wrote a few years ago while I was still at Uni took me (very roughly) 300 hours before it could compile itself. In this case I would have to design the language and write two compilers. The first compiler (or interpreter) would have to be written in an existing language to bootstrap the new language and the other one a native compiler (i.e. written in the language itself).

I have some idea of the main semantic features the language should have. The most important difference from C#, the basic integer type should allow for arbitrary-size numbers, as in Python. That's one important step Microsoft did not take.

I am still looking for a good inspiration for the syntax though. I'd rather not go into curly braces. I like a lot of ideas from Python's syntax a lot. However, in a statically typed language the lines can get longer and this might not work as well. I also consider taking inspiration from functional languages such as Haskell for function-call syntax (i.e. 'f x y' instead of 'f(x, y)') although this might not work well with passing keyword arguments (passing arguments with names explicitly specified).

In case you are wondering, yes, I already have designed a completely useless programming language (and wrote a compiler for it) and not published it. So I definitely do know I am perfectly capable of just that. Again.

There you have it, I spent the whole evening babbling. However, if the sum of time other people spend reading these posts exceeds the time I spend writing them, then vengeance will be mine! Maybe next time I will cover some less revolutionary, boring and virtual topic. Or not.

The woes of C

If I wanted to make this article look interesting, I would title it C considered harmful, but I will not. HelenOS is written in C. C is a programming language created at the beginning of 1970's. It's creation is closely tied with the birth of UNIX. At the time of its creation, C was a simple and yet extremely powerful programming language.

C maps (or can map) rather closely to the hardware. Originally it required no or very little run-time support. (What this means: a piece of code using only the core language -- not library routines -- can be compiled directly to machine code and does not require additional libraries or other support to execute).

For quite some time C has been showing its age. Both the core language and the standard library are becoming more and more inadequate for implementation of applications.

Working with strings has always been an extreme pain in C, but with multi-byte encoding (i.e. UCS/Unicode) it has become a nightmare. In HelenOS we decided to drop the standard C99 way of handling multi-byte strings altogether and implement our own. Needles to say, it's only a little better, the language won't allow us more. I demand automatic memory management! I demand user-defined operators!

String formatting in C is a chapter on its own. While this could be re-implemented in the standard library to be extensible (i.e. allow the consumer to register a formatting function for their custom type) we cannot really do away with the need to provide the type of argument in the formatting string, at least not in a sensible way. I demand virtual methods!

What usually drives me mad is the complexity involved in using a hash table in HelenOS. I need to implement several callbacks just to get my int->pointer map. I want generics! I demand collections!

There is a plan to implement a graphical user interface for HelenOS. Having to implement it in C is just giving me the Willies. We would probably end up with some monstrosity like GTK... or worse. I demand inheritance!

I demand a language worthy of the 21st century!

... to be continued.

What this blog is about

Now wait a minute... this blog has existed for a few months already, but the first post is dated today?! That can mean only two things: either (a) I am the laziest person in the solar system or (b) I prefer coding to writing about coding.

This blog shall deal mostly with my contributions and ideas for HelenOS. If you don't know what HelenOS is by the time you've finished reading this sentence, then you obviously have not followed the hyperlink embedded within it. Redo from start. Now you know HelenOS is a supercalifragilisticexpialidocious operating system.

This information is mostly targeted at fellow HelenOS developers and enthusiasts so I will probably not bother to explain all background for the average passer-by most of the time.

I might also blog here about other geeky stuff not related or vaguely related to HelenOS. That is, if I manage to blog at all. Because of (a) or (b).

Hey Jakub, I blogged! Jakub's been persuading me to blog about HelenOS for some time. So there. I've blogged. Blogo ergo sum. Although I don't have a MySpace account. So I don't exist. And I don't have FaceBook account nor a Twitter account nor a Peprnet acount and omega other accounts. So the cardinality of my non-existence set is omega. Doh.