So, this file is plaintext (using vm 1 omega m5 cmd sacas syntax, see below). Any old (or new?) text editor will let you alter it. This file is used as the basis for the Command Line Interpeter (CLI) which you interact with, and was used to generated the symbolic table tok::clicmd (i.e. the clicmd enumeration in the tok namespace), explicated in cmds.h and part of the executable builds.
The parser is expectation-oriented, and pulls data in as a continuous stream. However, it may be better to think of the file as line-based (with one line being any number of characters before a newline character, which terminates the line). Currently, commands can be stacked more than one to a line, but this is a bug rather than a feature and may soon be a non-option.
Each line-statement represents an instruction for the engine which is building the keyword dictionary, which the CLI (mt6.exe) will use to parse user input.
This is not the only file of this format available. The file "smt.txt" is automatically loaded at runtime; but not into the command dictionary but, rather, into the working dictionary of the tool. The CLI is only a driver to a C++ class which provides all of the functionality exposed by the CLI, and perhaps a bit more. This driver exists to demonstrate the power of the class, esp. in a way that non-programmers can appreciate.
At least, that's the goal. It needs a bit of work, and a lot of polish, in order to be more capable of presenting a good impression. However, its existance has already helped by showing shortcomings in the usage of the underlying technologies. As the saying goes, education is golden, even moreso than silence.
The first character of each statement should be followed by a space. Always. This space delimits the character, and looks nice. It also makes the file less ambiguous. It is also something Nelish did for the sMud configuration files, and I copied it quite blatently.
The magic first character (of each statement) can have a variety of meanings.
The hyphen ('-') indicates the end of meaningful data. It is highly advised that you use this appropriately.
-
Comment lines can start with a variey of characters, including the hash '#' , semicolon ';' , and forward slash '/'. Currently, they are no multi-line comments.
# [ comment text ]
; this is also a valid comment
for this type of sacas
/ as is this!
The main thrust behind the creation of this tool is to manipulate "dictionaries" of tokens, and to produce usable files (currently limited to C++ style headers) which are based directly on said dictionaries. Eventually, its usefulness will meet this ambition, as refinements continue. However, it is already useful enough that part of the tool can be, and was, built using the same tool.
Each token has at least one primary name, and one (and only one) magic number.
p [primary name] [magic number]
m [magic number] [primary name]
a [alias]
s [secondary name] [magic number]
Tokens can also be tagged with secondary names, or "aliases". All of the above commands define a new name, but only the first two define a new token. the latter two, define-alias (a) and define-secondary (s), are used to add secondary names to the dictionary. The difference between then is that, for 'a' , the alias is assumed to be a secondary name of the last defined token, whilst for 's', the magic number of the token to be aliased must be provided explicitly.
Each token can be tagged with a super magic number. In on application of tags, the magic number indicates the type of command, which is used in determining how many parameters to expect (remember, the parser is expectation based), as well as to factorize the parser logic (well, make it hierarchical). Token tags are declared as follows:
t [tag number]
Consideration is being given as to expanding tagging, possibly in an orthogonal way, so that more meta-dictionary information may be included. This would especially help in the "SE7" project, S+ Engine iteration 7, currently in progress.
I hardly ever get asked anything about my projects. This might be because no-one can understand them, or maybe because they are trivial and not useful to others, or maybe because nobody cares. However, I ask myself questions all of the time, especially years later when I look back on an old project. So, with that, at least in mind, here are some answers to questions which a stranger (or me in the future) may ask:
"VM1 omega m5 cmd sacas" seems like a set of gibberish, but it really has a meaning ; here is how to make sense of it: VM1 is the project, omega means work-in-progress (a prototype/plaything), m5 technically refers to the version of the first test harness (mark 5) which used the file format, and sacas stands for Specially Adapted CAS, which is the basis of the file format).
Note that although we are using a slightly improved test harness, the "mark 6", the sacas is the same identical format, as the sacas-loader-parser has not been changed functionally.
This stands, approimately, for "meta-dict-ionary tester, iteration 6", which is approximately what this tool is.
And, that's just about it. The file is fairly specific in scope, nothing much more to say about it. It took far too much effort to set this up, I guess, but in the process I learned a bit of C++ and stuff... and now I can do this stuff the way I want. Except that meanwhile I've thought of other things I can do, which will require a different expression altogether. Life is full of adventures.
Wednesday, 19 Apr., 2006.
Produced by K31 / Lord Granitor, under pressure and with perseverence, until success was attained and the fruits of labour were reaped.