• entry
1
4
• views
2360

Intermittent musings

## bcScript - A simple and small scripting language

As seems to be a developing trend amongst the journals (epoch, DeyjaScript, Aardvajk ), Iv also been interested in language design and building the programs to make it omething tangible. Iv briefly tried this a few times over the years, and this time around Iv got past the stumbling blocks that turned me off finishing it. bcScript is the name Iv given my attempt to follow the example in the book Game Scripting Mastery by Andre LaMothe (-source code), deviating where I either didnt quite follow the way he was doing it, or just wanted less features than he gave. It has a C style syntax, with planned support for objects and classes, as well as some more basic stuff like arrays and namespaces that I skipped when reading through the book. An example

//Example script#include "std.bc"function int fib(int n){ if(n<3) { return 1; } return (n-2)+fib(n-1);}function int main(){ int in=input(); in=fib(in); print(in); int t; while(t!=6) { //1 to 5 print(t); t=t+1; } return 1;}

Its simple, and it lacks anything OO or really that modern, but Im aiming to have a really simple API to make up for it. The code is split up into roughly 4 parts: the lexer, parser, code generator and virtual machine (or VM). The Lexer splits the text file or sometimes just a container of strings into tokens, similar to splitting a sentence into the indivdual words. Basically one big dirty switch statement, but with only a few special states for delimiters that have the same first character (= and ==, or + and ++). This stream of tokens is passed to the Parser, which then recursively passes over each token, with a set of rules that define what can follow after a certain token. It produces a tree structure (the wonderful tree.hh), as well as a few symbol tables containing information about things like variables, functions and literals. Many of the functions here are taken from the Game Scripting Mastery book, with the exception of creating assembly like instructions. I dont know why the choice was made to put another language inbetween the AST and the bytecode generation. The assembly is close to a 1:1 mapping to the bytecode anyway. Things like functions and their local data would make the methods a little more bloated, but thats all i can think of. Im probably misunderstanding the situation.

The Parsers AST (abstract syntax tree) and tables are pass to the bytecode generator. The work done in the parser for verifying the correctness of code makes this part relatively hassle free. Its surprising how simple the order of valid words is to form coherent intent, when you've abstacted them to broader concepts. On the downside, you loop over the same data multiple times, each time creating (an albeit more concise) representation of the input data as well. Back in the days of comparatively tiny memory amounts, there wasnt enough room to put all these duplicate representations of the same data to make it simpler for you to code. But Im glad. Code Generation is currently where Im at right now, and Im still fleshing out the bytecode design as I go. I see the VM being similar to the in effort to the generator.

Ill put some code and apps up soon hopefully; all this talk!