I'm writing a partial compiler for an 'in-house' scripting language based off C (like COG..) for that OpenGL project in thread:
http://forums.massassi.net/vb3/showthread.php?t=37630
I've been working on this as much as I can for the past few days, and it's coming out pretty good. Everything is being done by hand (screw Lexx and Yacc).
The resulting language is going to look pretty much like COG, which most everyone here is at LEAST somewhat familiar with. You will be able to declare new functions, and the scripts will be function-call based, versus COG's event messages. For example:
COG
Sodiumscript equivelant
Done and/or mostly finished:
- Lexical Analyzer
Converts program text into tokens. This filters out whitespace, comments,
some potential errors, converts text numbers into real values, etc.
Strings, vectors, floats, and ints are supported for value types.
Plans to support structures.
- Statements and Expressions
Abstract statements and expression interfaces and MOST of their derivatives
are done. if() checks, for/while/do-while loops, etc. are all done.
Stuff I need to do:
- Identifier scope
Without really thinking ahead, all identifiers are global in a script,
which is actually the way COG works, except I want to support functions
with parameters, which complicates matters, edging me towards localizing
identifiers to the depth they are declared/first used within. Therefore,
global identifiers could still be used as long as they are differentiated
from locals by either requiring global or local variables to have a keyword
identifying them. For example, LUA scripting uses a 'local' keyword to
declare local variables, while otherwise they are assumed to be global.
I may take this approach.
- Postfix operators
Function calls, subscripting, dot operator for structures, and
increment/decrement are postfix operators.
'Function pointers' probably won't be supported, but I do hope to support
a better subscripting setup than COG has. You should be able to at least
subscript into strings to retrieve a particular characters. I definitely would
like to support strings better than COG since they can be quite useful in
higher-level programming. At the very least, function calls will be provided
for string manipulation, if not at least a little native support. For example,
concat'ing strings together using + operator should not be very difficult.
The 'compiler' is pretty much going to lex the program contents and form the syntax tree for each declared function. That's it. No virtual machine or bytecode result. To execute a script function within the engine, a string or hash ID for the requested function is fed to the Script object, and it spits back a pointer to that function if it found it. From there, execute() can simply be called. This will recursively execute each contained statement, and evaluate each statement's contained expression(s)/statement(s). Currently, executing a function is finished and works. The lexer is finished and works as well. Statement forming is finished and works. Expression forming is pretty much all that is left, and that requires order of operations and determining what type of expression (unary, binary, postfix, value, identifier).
Like I said, there's probably not going to be an internal 'machine' language or virtual machine for sodiumscript, so it'll run slower. Executing the test scripts didn't dent the framerate at all, so I'm not terribly worried. One benefit to this type of setup is that scripts can be compiled and used on the fly, while running the game. I'd like to pop up a big text field using a debug command, and allow you to write an event handler (like onActivated) for the particular object you are targetting.
This is a learning experience, I plan to rewrite the whole damn engine and compiler when I get a better sense of how to go about all of this stuff. The code works but its rather ugly
http://forums.massassi.net/vb3/showthread.php?t=37630
I've been working on this as much as I can for the past few days, and it's coming out pretty good. Everything is being done by hand (screw Lexx and Yacc).
The resulting language is going to look pretty much like COG, which most everyone here is at LEAST somewhat familiar with. You will be able to declare new functions, and the scripts will be function-call based, versus COG's event messages. For example:
COG
Code:
symbols message activated model cereal=cerealbox.3do local end code activated: player = GetSourceRef(); dummy = GetSenderRef(); x = 50; call doSomething; SetThingHealth(player, healthVal); SetThingModel(dummy, cereal); return; doSomething: healthVal = x * 2; return; end
Sodiumscript equivelant
Code:
function onActivated(dummy, activator) { SetObjectHealth(activator, doSomething(50)); SetObjectModel(dummy, "cerealbox"); } function doSomething(x) { return x * 2; }
Done and/or mostly finished:
- Lexical Analyzer
Converts program text into tokens. This filters out whitespace, comments,
some potential errors, converts text numbers into real values, etc.
Strings, vectors, floats, and ints are supported for value types.
Plans to support structures.
- Statements and Expressions
Abstract statements and expression interfaces and MOST of their derivatives
are done. if() checks, for/while/do-while loops, etc. are all done.
Stuff I need to do:
- Identifier scope
Without really thinking ahead, all identifiers are global in a script,
which is actually the way COG works, except I want to support functions
with parameters, which complicates matters, edging me towards localizing
identifiers to the depth they are declared/first used within. Therefore,
global identifiers could still be used as long as they are differentiated
from locals by either requiring global or local variables to have a keyword
identifying them. For example, LUA scripting uses a 'local' keyword to
declare local variables, while otherwise they are assumed to be global.
I may take this approach.
- Postfix operators
Function calls, subscripting, dot operator for structures, and
increment/decrement are postfix operators.
'Function pointers' probably won't be supported, but I do hope to support
a better subscripting setup than COG has. You should be able to at least
subscript into strings to retrieve a particular characters. I definitely would
like to support strings better than COG since they can be quite useful in
higher-level programming. At the very least, function calls will be provided
for string manipulation, if not at least a little native support. For example,
concat'ing strings together using + operator should not be very difficult.
The 'compiler' is pretty much going to lex the program contents and form the syntax tree for each declared function. That's it. No virtual machine or bytecode result. To execute a script function within the engine, a string or hash ID for the requested function is fed to the Script object, and it spits back a pointer to that function if it found it. From there, execute() can simply be called. This will recursively execute each contained statement, and evaluate each statement's contained expression(s)/statement(s). Currently, executing a function is finished and works. The lexer is finished and works as well. Statement forming is finished and works. Expression forming is pretty much all that is left, and that requires order of operations and determining what type of expression (unary, binary, postfix, value, identifier).
Like I said, there's probably not going to be an internal 'machine' language or virtual machine for sodiumscript, so it'll run slower. Executing the test scripts didn't dent the framerate at all, so I'm not terribly worried. One benefit to this type of setup is that scripts can be compiled and used on the fly, while running the game. I'd like to pop up a big text field using a debug command, and allow you to write an event handler (like onActivated) for the particular object you are targetting.
This is a learning experience, I plan to rewrite the whole damn engine and compiler when I get a better sense of how to go about all of this stuff. The code works but its rather ugly
[ B A H ]
Bad *** by nature,
Hackers by choice
Bad *** by nature,
Hackers by choice