Archive for the programming Category

Making a simple programming language – preramble

Posted in programming, Rasp on January 17, 2011 by bbarrett

I’m just cleaning up the code for the first article in my planned series. In particular I scrubbed C++0x from it, because not everyone will support it.


I’m debating on whether to add extensive comments. I intend for this to be aimed at people who know C++, but the question is how well. I make liberal use of the standard library data structures and algorithms. I’m planning on keeping it a mid to high level discussion of the various problems and my solutions to them. I do plan to discuss the implementation itself but not in exhaustive detail.

Publishing Schedule

I think it will be worth taking some time to write up this base code, as it presents the foundation of the rest of the series. It is simple enough. For the moment, I support number literals and functions defined in C++. There are a small set of functions predefined, including the basic math operators and a print and println function. A function can be passed to another, but this isn’t particularly useful yet. It does allow one to implement a library function like std::accumulate(), where the operation to be run is specified as part of the data. I’ll probably have to split the initial implementation into three or so articles to keep them short and readable.

Implementation Stuff

So far I’ve implemented a simple value based system, everything is passed and returned by value. Functions are hard coded at compile time. This means that multiple invocations of a function will incur copies. This is fine at the moment as a function is just a string and a function pointer, but when I move to support user defined functions I don’t want to be needlessly be copying them around.

The current implementation merely starts a REPL interpreter. There is no support as yet for loading from a file or any command line parameters at all.

Show me the Code!

The code is available on github: I haven’t put in a build system or committed the Visual Studio project files as yet. I’m testing it on Linux too, so I’m not sure how I’m going to do that just yet.



Proto article series on creating a programming language – Roadmap

Posted in programming, Rasp on January 14, 2011 by bbarrett

There has been a lot of interest on the forums about creating custom programming languages. Since I have done this, I was thinking of doing a semi-retrospective, semi-rewrite to illustrate how to build a working programming language interpreter. I was considering doing this for quite some time, but I didn’t quite have the motivation to do so.


I’m going to start with a basic Lisp syntax, using a hand rolled parser. Integrating a proper parser is a hurdle that I don’t want to place too early in the process. I do plan to do it eventually so I can use a nice custom syntax. Most of my initial effort will be concentrated on getting the interpreter up to scratch. Its working title is “Rasp”, which is an ugly mix of my user name and “Lisp”.
Type System

I haven’t tied down all the details yet, but I’m aiming for a semi-dynamic language, with optional explicit but otherwise inferred strong typing. That is, a function can be written without mentioning types. If a variable are used in a context where the type is known (e.g. passed to a library function or explicitly typed) then the type will be inferred and an error occurs trying to invoke the function with an incorrect type. Types will be be inferred recursively, so a generic function calling a second generic function which calls a typed function will have the types propagated all the way back. In certain circumstances, I expect the type will not be deducible. For the moment, I’m going to do something similar to “autoboxing” where in such cases the program will generate type errors at runtime rather than compile time. A variable would be strongly typed, once given a type (explicitly via declaration or implicitly through first assignment) it would not be legal to assign it to an unrelated type.

Some or all of these ideas might be compromised if they end up contradicting each other, or if they overly complicate implementation or finally if they just aren’t nice to use. In any case, almost none of them will be present early on. Hopefully it won’t be too difficult to add them later.

Advanced Topics

Some of the more advanced things I’m interested in investigating are automatic type decomposition to enable “data oriented programming” without imposing a large burden on the programmer, or possibly an explicit way of separating the physical arrangement of the data from the logic arrangement, to put the programmer in charge of their data layout. Other ideas include a hybrid approach to memory, using RAII where possible and garbage collection only where cycles can occur. I think the type system I’m considering might cause the compiler to be unable to infer a useful type, it would end up inferring something like “Object” in managed languages, though I’d prefer to omit such an arbitrary base class from the language if possible. To achieve this I may be forced to use explicit types when defining data types. I’ll need to investigate.

I’d also like a language that helps programmers with multi-threaded code, or at least doesn’t hinder them in quite the same way that other languages do. The plans I have for this are more nebulous at the moment, we’ll see how it goes. Maybe something like language support for transactions, which can be rolled back and made a critical section.

I’m also thinking about an alternative to exceptions and error codes, or possibly merging them together – for example: checked return codes, the compiler will reject code that does not test the return value of marked functions. Investigate some kind of language support to ease the burden of passing error codes through a function call hierarchy, which might be aided by the inference engine I’m including. We’ll see.

Long term goals include optimising the implementation to the point that people might want to actually use it, and eventually JIT compilation using LLVM. I would consider targeting a prewritten VM but it don’t think it will allow me to get to some of the juicier advanced topics.

Coming soon

But the first few iterations will be very simple. I threw together an interpreter yesterday using my old “Lisp” project as a base. It lacks a parser. I’ll get something simple working for the weekend, during which I hope to publish (or at least write) my first “article”. I am currently testing it by building a raw instruction list and executing it. The first iteration will support integer literals and calling arbitrary C++ functions, hopefully even in a nested manner.

I started from scratch, not because I want to but because that is the best way to demonstrate the iterative process over the series of articles. Even stripped down to quite basic functionality, the base code is not small. I believe it is about the smallest useful size that will give me a good bit to talk about without being overwhelming. Hopefully it will be about the size that my intended audience can manage.

I know I can get it to the point where my last Lisp language was, which was reasonably powerful but with glaring omissions, notably user defined types. I should be able to get a few articles out until that point, then I can start braching into some of the topics I mentioned above.


The main complication is that my time is divided because I’m working on a game with a friend at the moment. We’re getting close to a potential test of a gameplay mockup, we’re aiming to have the program ready by the end of January and possibly conduct some tests in the months following.

Stay tuned,
— rip-off


Posted in blatent_self_promotion, Critters, GameDev, Java, programming, UFEC on March 7, 2010 by bbarrett

The deadline for UFEC approaches rapidly. I may not have sufficient time.

I have so much to get done, I have to take a clincal approach to my TODO list and cut anything that isn’t necessary. I’m just hoping there will be enough stuff left to leave a fun game.

One of the UFEC elements is fire. I’ve put in a simple rendering technique that makes decent looking fire, but I’m not sure that it will suffice. The entire game is done in immediate mode, combined with rendering not a small number of particles I’m worried that the game will perform well on slower systems than my dev machine. I have a simple optimisation that could speed it up a lot, but that would require time to write and test that I’m not sure I have. Water rendering and handling is something I’m hoping to do today.

Input is a huge concern. The game game feels awkward to play at the moment. I really want to have a mouse only interface, but it is tricky. The problem is that I can reduce the number of actions that the user might need to perform at once to three, but that means relying on the middle button, which never really feels comfortable to hold on. Holding down the button is an essential part of each of the three actions – pan camera, select critters and “apply current mode”.

The current modes are currently “proliferate”, “evolve” or “attract critters to mouse”. The really ugly temporary UI I have implemented for them will eventually be usable by clicking on the icon of the action you want to perform, with shortcut keys available too.

My evolution element is very weak at the moment, I have evolved types but they act pretty much identically to the “default” critter type. They are drawn a little different, but not even *that* different.

Some of the other things I was working on is getting levels to transition and keeping the camera inside the bounds of the map. I also worked on giving feedback for when a critter is injured, they flash red briefly. I still need to add some visual cue for how healthy a critter is.

Some more good news is that I’ve broken my level editor mode (which I haven’t touched for a while). I’m going to have to design some levels for this game, which I’m not feeling confident about. Hopefully it won’t be too bad.

This week is probably going to be crunch mode. I’m considering taking a day or two off work coming up to the deadline to try get this done. I’m just hoping that my enthusiasm holds steady. And perhaps my sanity.

Short video featuring some of the changes I’ve made:

Java GIF transparency stuff

Posted in Java, programming on December 2, 2009 by bbarrett

Still alive.

At work last week we had a problem with transparent GIFs. Our Java program needed to be able to resize images. However, the approach taken worked with all tested formats except transparent GIFs.

After searching the internet for a while, I was able to piece together a solution that a) worked and b) avoided unnecessarily allocating memory (which was a “feature” of most other solutions I found). It appears this is a relatively common problem, maybe some lost soul in a similar situation will find it helpful.
Continue reading

User defined macros

Posted in LISP, programming on December 21, 2008 by bbarrett

I have just finished hacking in user defined macros. For the moment they look like they will be up to any use I want to make of them at the moment. They are fairly simple, they are syntactically similar to functions. They must return a list. This then replaces the invoking code during compilation.
Continue reading

Back from beyond the grave

Posted in LISP, programming on December 15, 2008 by bbarrett


Long time, no post. I don’t really have an excuse for that. Just generally being busy and not having a huge amount of time for personal projects. Hopefully I will get a little time over christmas.

I’ve done a little here and there, but nothing that seemed worthy of an update.

Today, I have started back into my Lisp interpreter. I fixed a load of minor bugs. I’ve added small amounts of other functionality. For example, I have added a type, similar to Lua’s lightuserdata. To test it, I made a set of functions for file manipulation. That, combined with the eval function I already had allows me to define (purely in Lisp) functions for including files.
Continue reading

I am an idiot.

Posted in LISP, nonsense, programming with tags , , on September 11, 2008 by bbarrett

I have just figured out where I am going wrong. All my variables are stored on the LISP stack, which is a std::vector<Cell> instance, (Cell is the variable type). Some of these Cells themselves contain Standard C++ Library objects (lists use std::list<>, functions are std::vector<Instruction>, strings are std::strings), and references to those objects are stored on the C++ stack during operation.

A few functions deep, when stuff keeps being added to the stack, it eventually will reallocate and… boom, all my iterators and references die a horrible death. Took quite a while to figure out that this was going on, I was preoccupied with assuming there was an issue with the Cell’s implementation of the Rule Of Three. I had already had issues with that, as I mentioned before.

For the moment, a “quick fix” is to manually set the initial stack size quite high. I think with this my current implementation works fine, but I hate such an ugly fix, which is too brittle anyway. I could choose std::list<>, so elements won’t be moved around in memory, but there might be another way.

That took far too long to diagnose…