A syntax for IRON (by alaric)

Back in 2004 I jotted some notes on requirements for IRON types.

Since then I've been drifting somewhat towards looser typing, in the Lisp model; having that as the underlying system provides for more expressive programming power, while optional type declarations as assertions, where required, can bring back the statically checkable safety and runtime efficiency of a strict type system.

But that's not what I'm posting about in the current insomniac haze - I've been thinking about written syntax.

IRON is a data model for values. Although I'm still deciding how the mutable data structures like queues fit into things (specifications of them are definitely needed for TUNGSTEN, but whether they count as part of IRON or not is something I'm still debating), I think I may have settled on a basic syntax for written values.

Now, the key requirement here is that IRON is, in the manner of S-expressions, usable to express just about anything - from source code to boring data. Creating a written data syntax that's pleasant enough to use day in and day out is quite a challenge. s-expressions come pretty close, but are deficient in a few areas. YAML is pretty good, but I wouldn't want to write source code in it.

The main thing I'm adding over s-expressions is Smalltalk-like syntax, which I will explain in detail below.

So, without further ado, here's a basic IRON syntax.

Read more »

What I want from a programming language (by alaric)

I'm interested in programming languages. When I was a kid, I'd get books on different languages out of the library, and sit and learn a language. I didn't get to write code in many of them, since this was before I owned a modem; all I had at home where BASIC, Z80 assembly language, Pascal, x86 assembler, then C and C++. But I devoured new languages whenever I could. When I came across FORTH I wrote my own implementation (although at the time I didn't get the metaprogramming stuff), since FORTH is easy to implement (it's a great bootstrapping language), and later on, I implemented a kind of Lisp as a scripting language for a game engine (except I used a Prolog-esque syntax, foo(bar,baz) rather than (foo bar baz)). I really wanted to play with the rich feature set of Ada, and the parallelism of occam. I studied COBOL and FORTRAN and found they didn't look much fun. I studied Smalltalk and found that it looked like great fun. Prolog was interesting, a radical departure, but I saw it as foolish to write whole programs in it - I felt it should be used as a database query language like SQL. It's Turing complete, but a large class of programs are ugly to write in it.

Read more »

Secure bootstrapping (by alaric)

Back in the day, Ken Thompson described a rather scary problem with the way programming languages are compiled.

In summary, one could modify the C compiler so that, when it compiled some security-critical application like sshd, it inserted a security hole. The pristine sshd sources, when compiled, would produce a vulnerable executable. But then to protect the modification to the C compiler from being found, one can use the same trick on the compiler - make it insert the bugs into sshd and into itself when compiled from pristine sources. Compile this compiler up, then test it on its original sources, and when it's all working OK, install it on a system (and the bad sshd) and remove the dodgy sources. Clear your .bash_history and you're done 😉

Read more »

One Size Fits All (by alaric)

On Monday, I happened to be discussing some ARGON stuff with a friend, and he pointed out that what I'm trying to do, in many ways, is to find a one-size-fits-all solution for a lot of problems, and that this is often dangerous since you can end up making a nasty compromise.

He's right - part of the challenge in designing ARGON has been to find ways to avoid nasty compromises. So I thought I'd describe a few techniques I've been using.

Read more »

The structure of network protocol suites (by alaric)

It's always struck me as odd that IP routes a packet to a transport-level protocol such as UDP, ICMP, or TCP and then lets that protocol handle routing it to an application process.

Since an application is likely to require a few different types of service for different parts of its operations, shouldn't the specification of the target application be more important than the transport mechanism?

Wouldn't it make sense to be able to send a UDP request to 'port 80' just as easily as you can send a TCP request, rather than requiring the web server to bind separate UDP and TCP listener sockets?

These chains of thought led me to design the MERCURY protocol.

Read more »