I've decided to just postpone worrying about cycles and memory leaks in Om for the time being. I may have to address this in the future, but for now I've discovered that there are actually so many things the user can do that cause leaks, infinite loops, stack explosions etc that I cannot efficiently detect or prevent, that the memory leak issue with a cycle is only one small issue.

So I'll put this at the back of my mind and continue on with what is otherwise a pretty solid little language.

This morning I've been playing around with building Om as a static library and linking it into a standalone test application. The static library is 900 kb in size which is nice and small, and the test application, which just loads a script and prints some output to std::cout at the moment, feels quite nice and tidy. Figuring out the PRO file settings to build the lib was easy enough. If I'm going to start developing Om in this model I'll need a better workflow but for now I'll probably keep developing Om in its test bed context, which is a command line application, then update the file in my lib directory when I hit milestones.

Obviously I'm planning to use Om in my games as a scripting backend, but I've also thought I'd like to be able to use it on a day to day basis for sort of batch and general purpose usages, so I think I'm going to put together something that allows me to write an Om script in a text file, then execute it from Windows explorer with a right-click or something, so I'll probably get working on some kind of context program for this. I come across tasks in my day to day work that I could easily benefit from being able to run a quick Om script to solve so be nice to have this working on my computer.

As well as the context to execute it, this is going to involve slowly developing an Om standard library for things like file streams and so on. Best if this is just done as I go along and I need things. Perhaps this will form another static library for now that I'll link into my desktop context program. Om was designed to be extensible in this way, so that the library can be developed independently from the core language itself. We shall see how well this works out in practice.

I think it unlikely that cycles will be accidentally created in normal use and part of me just wants to say "Don't do this" rather than start to try to develop some kind of complex garbage collection system. I don't see how any system is going to work in all cases anyway and keeping this simple and robust is my chief concern.

I'll be updating this post later. Few bits to do this morning and time is a'wasting.