The Ackermann Function

Apropos of nothing, here’s a Grace version of Ackermann’s Function inspired by Sam Tobin-Hochstadt’s Racket example:

One interesting thing to note is that the condition after elseif is in {braces}, while the conditions after if is in (parens). This makes logical sense — because the first condition is always evaluated — but is of course inconsistent with every other condition.  (Apologies for the fixed-width font.)

Code as Literature?

Peter Seibel’s blog post Code is not Literature has generated some discussion in our department. I certainly agree with a lot of what Peter writes — when I used to coordinate our final year design patterns course, students would present examples of patterns culled from the Interweb. (Google code search was great until it was switched off). Let’s just say even finding patterns clearly expressed in code was often a bit of a struggle. So I’m quite sympathetic to Peter’s point that “most real code” isn’t really worth reading.

On the other hand, I still like Richard Gabriel’s idea of the “Poetry of Programming”. Donald Knuth’s Tex and Metafont have been published as hardbacks; Kernighan & Plauger’s Software Tools & the John Lions’ Unix book as paperbacks. One of the things I like about Smalltalk and Self was the way the IDE made code easy to read, and that much of the system code had obviously been written to be read. Now Github & SourceForge mean there are millions of lines of code around that can be read anytime: but that still doesn’t make it literature.

I guess this is because literature doesn’t happen by accident. Most writing isn’t literature — this blog post, my university’s assessment handbook, company procedure handbooks or advertising brochures may be grammatically correct and be worth reading for the content they contain: but they aren’t worth reading just for the sake of it. So we shouldn’t be surprised that most of the code isn’t literature: it doesn’t need to be.

What’s this to do with Grace? Two things, I think. First, we hope that Grace is a good language not just for writing code day-to-day, but also for code that aspires to be literature. And second, we hope that at least some of the code we write in Grace, while it may not rise to literature’s exhaled state, will at least be worth reading.

Three Talks on Grace

In the next couple of weeks, there are three talks on Grace.

First, a virtual talk — a video Michael Homer’s talk at last year’s Strange Loop is now online

Second, this coming Tuesday, James Noble is talking about Grace in Vancouver at The University of British Columbia — 4pm Tuesday 7 May.

Third, as part of ICSE, James will be talking specifically about Can an Introductory Programming Language Support the Teaching of Software Engineering? at the CSEET conference, at 3pm on the 21st of May.

James is travelling to Vancouver, Pomona, then up to the Bay Area and San Francisco between now and then, if people would like to talk about Grace.

Laissez-parlent l’Eiffel!

The Eiffel language has many features that support software engineering. One of these is a loop statement that allows programmers to specify loop variants and invariants. We hope Grace may also be used to teach about invariants, so it would be useful to write Eiffel-style loops in Grace:

The key here is the loop/invariant/until/variant control structure — which in Grace is just a method that takes Blocks as arguments. Here’s a simple implementation of this method:

Of course, in a practical Grace system, this method, like other control structures, would be defined in the system or dialect library. The key features that make this possible are not themselves complex: multi-part method names support defining every control structure (syntatically and semantically) as a method request, and then using blocks to pass code into those methods.