An introduction to SML

Since the dawn of time I've been (for unknown reasons) unreasonably interested in parsing strings of text. I have no idea why, but for some reason the idea of solving the problem of making a computer make sense of text have always been a pet problem of mine. My first major projects, plural, when I first learned programming (in Visual Basic) involved parsing text in one form or another. One of those projects was a crude MP3-player that was script-able in a crude language I made up that was mostly inspired by the scripting in the first Half-Life engine.

A year or so ago I undertook a project in designing a scripting language. I made an interpreter for it over a few weeks of work and it did work, but it was a very crude and inefficient engine (as was the language). I do like the idea of the language that I came up with and it did have some interesting points, and I hope to keep designing and writing it during off times, while blogging about it. Hopefully it will make for some interesting articles; I know I will personally learn a lot. I won't go into too much detail about the language in this post, but I might as well write about some of the more general points and the design philosophies.

I'm calling the language SML, which is short for Simply/Scripting Markup Language. Sadly the abbreviation is already taken by another language, so I will have to change that (perhaps SSML but that sounds corny). The name will stand however, since it reflects what the language is supposed to do just perfectly. My idea, or what I want to do with it, is to design a language that blends a markup language akin to XML (just simpler) with a scripting language.

The idea of the language is not to make it useful, for me it's a learning experience, and I believe it's an important experience. It's also something that I am very interested in anyway. Hopefully someone somewhere will find the language useful, but God knows there are enough programming languages as is. In either case I will start a series of blog posts related to the language, covering areas that come up when writing a language. The first post will be about parsing expressions, quite an interesting topic on its own.

(In case of interest the old interpreter can be found here, but it does not reflect what the language will be very well. A lot of the design decisions, even in the design of the language, are flawed. Indeed I knew that when I wrote it, I just wanted so see if I could do it. I could, for some definition of could :).)