Smalltalk is a DSL

April 1st, 2009

After reading Torsten’s nugget of truth in Planet Smalltalk recently I couldn’t help but be reminded of a Smalltalk based language I’ve been throwing around lately. Not because my language is interesting yet—I don’t even have a prototype concrete syntax—I’m actually referring to my immediate reaction when he wrote:

“Smalltalk is not a language — it’s a dynamic object system with the language built in… [sic]

This is, in my opinion, more cautious than it needed to be. Smalltalk really is just a dynamic object system, but beyond that, I would argue that the language is really just a collection of DSLs.

The first, method definitions is kind of the core DSL of Smalltalk. While not necessarily as small as a simple DSL it provides all of the behavioral elements that make Smalltalk code actually do stuff, all of which can be replicated by generating AST objects, programatically.

More obvious however, is the class definition syntax. This quasi-message-send actually causes so many hacks and side effects that suggesting that it resembles any kind of message programmers would be comfortable sending normally is just outrageous! Really it describes the structure of a class and allows us to manage that structure. Oh, we can also file-out that sucker, too!

(The OMeta parser generator can also be used to write methods. The tool support was iffy last time I looked at it though.)

My point is, Smalltalk is really just a collection of DSLs that allow us to effectively program with a pure object system, and it’s this phenomenon that I will allow us to dramatically improve both the appeal of the language as well as its usefulness in the future.

— Lorenz

Tags: , , , ,
Posted in Opinion | No Comments »

A Pythonic Diversion

January 27th, 2009

smc-front-page
With all this Haskell programming and a rather lengthy predicted alpha data for the Haskell game engine, I started to wonder about my last game development project. Actually, it’s probably more accurate to say, I was looking over the Secret Maryo Chronicles forums and remembered how much I wanted to create a similar game, obviously with a somewhat different gameplay and tools.

See, this story goes further back to when I was still learning the basics of Haskell. I’d produced a simple game demo, but made no real progress in adapting that code base into something that would scale to a full game. That’s without considering the game specific tools either. My solution was to start a new project with the explicit goal of simply creating an actual game and level editor, based on the existing assets from Secret Maryo Chronicles placing the game under the same GPL license.

Since this isn’t the most graphic story from here, we’ll cut back to the present, which brings me to the first simple tech demo since I restarted the project. Its not much yet, just some code to test some basic view layout containers—the Shoes style stack and flow, although the larger design is inspired by Hopscotch more than Shoes.

I should probably point out that the entire program runs on wxPython and OpenGL, but doesn’t use the wxWidgets controls, but rather a uses a simple custom framework designed for rendering directly in OpenGL. This is meant to simplify creating the in-game menus and since the editor will need to utilize many of the in-game graphics anyway, not to mention the level test functionality, it will probably help there too.

This demo doesn’t do much really, it’s just a simple stack and flow layout container test, with a few image views. Also, you’ll need the wxPython, PyOpenGL and the Python Image Library (PIL) for this one. There is a fallback library, but I haven’t fixed a minor image flip but in the usage of said library, so the images will appear upside down. The demo should appear similarly to the screenshot below. (I found I had to move the window to get the OpenGL view to start drawing. Since I’m not developing on Mac OS I didn’t realize until I grabbed the screenshot for this post itself.)

screenshot2

To checkout the simple view framework demo for yourself, simply run the following commands (or for the git users out there, its on the demo-view-framework-1 branch.)

git clone git://github.com/krysole/smc-ma.git smc-ma
cd smc-ma
git checkout demo-view-framework-1

Then running the command python main.py should start the code.

– Lorenz

Posted in Gamedev | No Comments »

Just a little bit of progress

January 22nd, 2009

Well, its been somewhat slower going for the implementation of Fire lately. The interpreter I’m implementing is fairly simple, just an AST and direct interpretation of that, kind of like a Lisp meta-circular evaluator, but it has been surprisingly difficult to get around the complexity of the interpreter. I’m starting to thing this project may take a little longer than I originally expected, but that’s OK, it’s still been quite a lot of fun so far.

The biggest hurdle I’ve stumbled on over the past couple of weeks is getting the actual interpreter doing anything at all. There’s plenty of code sitting in the modules, but none of it can actually work since I haven’t quite managed to finish the implementation based on the design in use.

So Fire is basically just a heavily modified Smalltalk (or Self.) Most of the semantics are the same, with the significant exclusion of directly modifiable variables—but even those are supplemented with transaction variables and more functional programming facilities. At least that’s the design of the language so far.

The problem is that Fire, like Smalltalk, uses strict evaluation and at least some of the methods may need to, gasp, perform IO! To actually implement something like this, I have to implement the strict evaluation using the IO monad, even if it’s only by composing monads (or similar.) The story doesn’t quite end there though.

Programmers can also define local methods within a method in Fire. These methods are part of the lexical context, and correlate to the respective extension to the message send syntax. This means that the lexical context must be threaded through the evaluation of statement in a method.

Also, not all method calls return successfully. The return operator is also a variation of the normal return from a message send. The design of Fire here, calls for the usage of an Either return value, where the Left constructor provides a Fire exception object.

We would essentially like to hide the general flow using a monad for these two so that implementing methods for Fire in Haskell is as straight-forward as possible, not to mention the implementation of the interpreter itself.

So the decision I’m going with at the moment is to ignore any direct IO, which may eventually have to be reified back in later on, as well as transactions which should be a little simpler to put back in, and create a monad that captures both pieces of information. In theory, maybe it’s possible to implement this by combining monads—but the truth is, I’m just not that good yet. For that matter, this will be the first monad I’ve implemented (besides simple examples.)

Before I attempt the new design for the interpreter however, I also have another task I’m looking at which should be the topic of my next post. Testing Parsec parsers. All I’m going to say for now is that it involves QuickCheck, possibly because I haven’t actually finished writing the code yet. Until then, back to coding for me.

– Lorenz

Tags: , , , ,
Posted in Gamedev | No Comments »

« Older Entries