Programming Language Mix-Up

Last time, I talked about TADS 3 and Groovy. I noted that TADS 3 had features especially suited for IF—undo support, a concise, declarative syntax for game content, a special syntax for defining IF-style command-line grammar—and some other features I really liked, but that for some reason I still felt like I preferred Groovy.

Why? Not-invented-here syndrome, in a sense. The IF system I would like to work with is not nearly the system that the TADS 3 language and libraries help out with. Just to name a couple of cases, I dream of experimenting with undo history and parser grammar beyond what the TADS 3 system and grammar syntax support. This wouldn’t make TADS 3 a bad language for the job, but I expect this would make its domain-specific features into dead weight when they didn’t suit my needs, and when that happens I’m afraid I’ll find myself programming in a domain-limited equivalent of Groovy after all.

Since Then

Between the time I made that post and now, a few months have gone by, and I’ve done a lot of different things:

  • I took a deeper look at Inform 7.
  • Reassured that neither TADS 3 nor Inform 7 sat perfectly well with me, I spent some time pondering what kind of IF system design I was really looking for.
  • I re-implemented my website as a PLT Scheme servlet, and in the process I taught myself PLT Scheme (not to mention what a servlet is). It turns out I have no excuse for continuation dispatching anywhere on my site yet—it’s entirely static, in fact—but that was the draw for me (not to mention that I’ve always wanted to use some kind of lisp on a project).
  • I taught myself enough to set up a VPS with an Ubuntu-Nginx-MzScheme stack so that my site would actually run. You can see it now at
  • I refactored some JavaScript code for a Mega Man IV and V password generator I wrote back in 2007. (There are two games, but it’s essentially one generator because the passwords have so much in common.) I fixed some potential memory leaks, separated the code into its own file (rather than dumping it in the same page as the HTML), and cleaned up the API considerably, not only for its own sake but also so that any future password generators I might make could have APIs consistent with it. And then I went and posted it on my website.
  • I spent some time working on a Game Boy disassembler in Groovy. It’s actually a pretty awesome disassembler right now, at least for my personal use, but it isn’t exactly an end-user product. It’s organized so as to be extremely configurable (to support SNES or GBA disassembly, for instance), so it’s more like a disassembler library/framework for programmers to use. I’m comfortable with that, too. After all, if you’re using a disassembler… you miiight be a programmer. ^_- Still, a product for programmers could still be packaged up nicely for programmers, and this project isn’t quite there yet.

In this time, I was immersed in a heaping helping of languages (Inform 7, PLT Scheme, Nginx configuration files, XHTML, CSS, JavaScript, Groovy, and Game Boy assembly, not to mention that I lurk on the Arc forum and try to help out with rules debates on the Magic: the Gathering forum), and I had a bunch of thoughts about language design.

I was hoping one of these ideas might fester into meaningful blog post material, but the “next blog post” project hanging in the back of my mind never seemed near to completion. And my theme for this blog is projects I think about but which are potentially too grandiose for me to complete anytime soon. Irony. If only the irony of not having anything to write about writer’s block were worth writing about.

Instead of waiting any longer, I’ll just tell you my half-thought-out ideas and get it over with! ^_^ I may revisit them and flesh them out in the future, if I’m lucky enough to figure out how I want to do that, but for now this is what I’ve got.

Couldn’t Be More Natural

When I was studying Inform 7, the syntax was very overwhelming.

From the Wikipedia article:

“Hello Deductible” by “I.F. Author”

The story headline is “An Interactive Example”.

The Living Room is a room. “A comfortably furnished living room.”
The Kitchen is north of the Living Room.
The Front Door is south of the Living Room.
The Front Door is a door. The Front Door is closed and locked.

The insurance salesman is a man in the Living Room. “An insurance salesman in a tacky polyester suit. He seems eager to speak to you.” Understand “man” as the insurance salesman.

A briefcase is carried by the insurance salesman. The description is “A slightly worn, black briefcase.” Understand “case” as the briefcase.

The insurance paperwork is in the briefcase. The description is “Page after page of small legalese.” Understand “papers” or “documents” or “forms” as the paperwork.

Instead of listening to the insurance salesman for the first time:

say “The salesman bores you with a discussion of life insurance policies. From his briefcase he pulls some paperwork which he hands to you.”; move the insurance paperwork to the player.

This language bears a striking similarity with English, as you might have noticed. When I see this, I can’t help but think that I don’t know what part does what, exactly, and that I’m fooled into reading the surface English meaning rather than the meaning inferred by the compiler. Fortunately, there are plenty of tutorials on the language, and I’m sure it’s quicker to be confident in this syntax than in some others.

While I was distracted by this new syntax, I remembered another syntax in the same sort of family, which I’m quite comfortable with: Magic: The Gathering card syntax.

When Elsewhere Flask enters the battlefield, draw a card.
Sacrifice Elsewhere Flask: Choose a basic land type. Each land you control becomes that type until end of turn.
(Elsewhere Flask)

Split second (As long as this spell is on the stack, players can’t cast spells or activate abilities that aren’t mana abilities.)
Target creature gets +5/+5 and gains shroud until end of turn. (It can’t be the target of spells or abilities.)
(Stonewood Invocation)

If a spell would deal damage to a creature or player, it deals that much damage minus 1 to that creature or player instead.
(Benevolent Unicorn)

It got me to thinking, just how much more can Inform 7 and other programming languages learn from games like Magic that have dynamically changing rules? Maybe some sort of tabletop-game-inspired module system could be cooked up, which would allow for compile units to contradict each other and modify each other, and even ride on the state of a dynamic system, with well-defined behavior… behavior even non-expert humans get the hang of executing.

Right now, it’s just a solution looking for a problem, but I imagine a tabletop-game-inspired programming language or framework would at least be especially well suited to the implementation of tabletop games, if nothing else. Inasmuch as systems like IF works and adventure games can be mocked up in tabletop game dressings, it might be a suitable fit for them, too.

Don’t Pick on Lisps

One thing I’ve noticed about homoiconic programming languages with s-expressions (Common Lisp, Scheme, Emacs Lisp, Clojure, Arc, HL, etc.) is that people lump them together a lot.

See? Even I’m doing it. (I spent the last section lumping legalese dialects together, too. What’s next? Curly-bracket languages?)

A seemingly popular topic among fans (or detractors) of lisps is to talk about why these languages aren’t more popular and what can be or should have been done about that. I’m finding this to be a less and less interesting topic.

Homoiconicity (having code be written in the same format as data literals are) is a great feature in a language if you want to manipulate code as data. Who wants to do that? Programmers. All programmers. Programming is the manual process of manipulating code as data.

That doesn’t mean every programmer benefits from a homoiconic language. It just means, for all the programmers, computer scientists, mathematicians, and philosophers in the world, there are a lot of ways to imagine manipulating code as data (in fact, an insurmountable amount, inasmuch as we would like a language to solve the halting problem), and so a homoiconic language’s work is never done.

Lisps are doing fine. There is no flaw that binds and dooms them all. But they’re not a great end-all and be-all either.

Yes, I’m totally a hypocrite for writing this. I’m talking about lisps without talking in-depth about features of lisps. That’s why I’ve been putting off posting this; I figured I’d come up with something better to say. And I may, but then that would do better as a post of its own rather than one polluted with this rhetoric. ^_^

CSS Is a Hammer, and Keyword Parameters Look like a Nail

I was refactoring my Mega Man IV and V password generator JavaScript code, just minding my business, when suddenly I discovered the joy of keyword parameters.

I wanted the API to be useful in case someone wanted to put multiple copies of one or both generators on the same page, but that wouldn’t be possible under the current setup, which required every form field to have a specific id attribute. Not only would duplicated id attributes on a single page be bad XHTML, but it would also make it impossible for the two generators to distinguish those fields from each other. My solution, for the moment, was to add a parameter to the generator initializer that would specify a prefix to put on each of the ids it expected. This way, two generators could be initialized with different prefixes, and the fields could be labeled in a way that wasn’t ambiguous.

However, this is not a solution that gives complete control to the person using the API. For instance, maybe someday someone will want to use very specific ids on their page for some crazy-but-true reason, and it would be nice if they could specify each and every one of those ids for the initializer… or maybe even a callback function that accepts ids and returns references to page elements on the fly.

Now I have three ideas for how to provide this customization point, one with a quick syntax (just a single prefix string) that probably suffices for all actual cases, one (an id-to-id map) that’s nice for some offbeat cases, and one absurdly powerful option (a callback) that represents what all the other options would ultimately be used to generate anyway. Which should I choose?

Well, I had just come out of programming my website in Scheme, where I had gotten used to using keyword parameters to make them optional.

Also, I couldn’t help but notice that CSS gets away with having a whole lot of border properties that all represent various parts of the same information:

border-top        border-right        border-bottom        border-left

border-top-style  border-right-style  border-bottom-style  border-left-style

border-top-color  border-right-color  border-bottom-color  border-left-color

border-top-width  border-right-width  border-bottom-width  border-left-width

I chose to take a lesson from CSS and have the API potentially support many different keyword parameters all for the same thing, giving an error if the caller overspecifies the parameters in a way that doesn’t make sense. Having made that plan, I implemented just the prefix option (all I need so far for personal use) and moved on with my life.

I explained all this because it got me thinking about the relationship between keyword parameters and metadata, as exemplified by CSS. When you’re using CSS and HTML, you “tag” your HTML tags with class keywords and define what those keywords mean in the CSS. Many of these keywords, like border, were taken care of by HTML attributes before CSS came along. Those attributes are no longer necessary because CSS essentially sets them for you. (Technically, it’s more the other way around, I think—as in, style-like HTML attributes are less fundamental to the document’s style representation than CSS is—but I’m going to pretend for now.)

In Groovy, a common idiom is to use “markup,” declarative code that’s shaped like XML. A tag is created by calling a method (the tag’s name) with some keyword arguments (the tag’s attributes) and a closure (the tag’s body), which can contain more method calls like this one. This is done to generate XML code and to construct Swing GUIs, for instance, and it can be used for other kinds of in-language DSLs as well. Regular Groovy code fits right in with this, so it’s easy to use variables and looping constructs for templates and repeated sections.

(I haven’t tested any of the following Groovy, and it isn’t very beautiful code in some places, but the general syntax is all I’m trying to show anyway.)

def show = myMarkupBuilder.slideShow( defaultDuration: ) {
    img( src: "normal-photo.jpg" )
    img( src: "crazy-photo.jpg", zoomFactor: 2, rotationDegrees: 40 )
    vectorArt {
        int r = 10;  // radius of a single circle, and margin between circles
        int n =  5;  // number of circles
        rectangle( left: 0, top: 0, width: 200, height: 4 * r, color: BLUE )
        for ( x in (0..<n).collect { (it * 3 + 1) * r } )
            ellipse( left: x, top: r, width: 2 * r, height: 2 * r, color: YELLOW )

But can it do what CSS does?

Before I answer that, I should mention that Nginx configuration files use a syntax very similar to both this and CSS. It’s a header with a tag name and some parameters, followed by a body area within curly brackets, or in some cases followed by no body at all. (Didn’t I tell you there’d be curly-bracket languages? Only one of them is a programming language, but still.)

Back to the question: Can Groovy markup take advantage of CSS techniques? Actually, it can simulate parts of CSS without much effort. For instance, here’s a simple way to define parameters in one place and use them in another, achieving is the kind of abstraction CSS classes provide:

def briefClass = [ duration: ];
def subliminalClass = [ duration: ];
def crazyClass = subliminalClass + [ center: [ 200, 200 ], src: "crazy-photo.jpg" ];

// A class maker like this can be used when the parameters you want to specify when
// defining the class aren't necessarily the parameters the markup method accepts.
def ellipseClassMaker = { Map options ->
    if ( options == null || options.empty ) return [:];
    return options.collect { k, v -> (
        if ( k == "radius" && v in Number )
            return [ width: v * 2, height: v * 2 ];
        return [ (k): v ];
    ) }.sum();

def sampleCircleClass = ellipseClassMaker( radius: 200, color: PURPLE );

def show = myMarkupBuilder.slideShow( defaultDuration: ) {
    img( src: "normal-photo.jpg" )
    img( briefClass + [ src: "brief-photo.jpg" ] )
    for ( frame in 0..40 )
        img( crazyClass + [ zoomFactor: 1 + frame / 40.0, rotationDegrees: frame ] )
    vectorArt { ellipse( sampleCircleClass + [ left: 20, top: 20 ] ) }

Unfortunately, this still doesn’t achieve a large part of what makes CSS great. CSS can style an HTML document without using CSS classes at all, by using selectors that apply to nodes based on those nodes’ names and attributes, and by selecting nodes based on their positions relative to nodes from another selection. This sort of recursive data structure querying is a natural fit for Groovy, but if you want to do a query and apply a style, you depend the markup builder to provide enough of the XML-shaped data directly in its result for you to find and modify. And even then, you can’t get all the loop and variable information out of the plain Groovy code you used. (Actually, Groovy does let you manipulate Groovy code as data, but it isn’t easy yet.)

So part of me is wondering, just like with the tabletop-game-inspired programming system, what a stylesheet-inspired programming system would be like. What’s a superficial enough parameter in the code that it’s worthwhile to pretend it isn’t there and let a stylesheet handle it? Hmm, it seems like that would cover just the same (exc)use people find for using global variables, heh. It could also specify what namespace a part of the program uses, but then module import lines do that already. I imagine it could be used to separate the concept of a program from its optimization, in a way that may be similar to Common Lisp “declarations” (not that I’m familiar with those), but I think optimization would need more extensive program transformations than just parameter insertion, so it would just end up being a macro system at some point.

In the end, I don’t really have a clue what CSS-style programming would be good for. As with all these ideas, though, I guess I’ll have it at the back of my mind for when it’s ready.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s