voodoo::parser* parser = new voodoo::parser();
voodoo::tree* tree1 = parser->parse("example/test1.voodoo");
voodoo::tree* tree2 = parser->parse("example/test2.voodoo");
voodoo::tree* tree3 = parser->parse("example/test3.voodoo");
voodoo::tree* tree = new voodoo::tree();
tree->add(tree1);
tree->add(tree2);
tree->add(tree3);
tree->merge();
voodoo::code* code1 = tree->compile(tree1);
voodoo::code* code2 = tree->compile(tree2);
voodoo::code* code3 = tree->compile(tree3);
// at this point code1 through code3 can be saved to disk, and loaded back again.
// but the tree (or the different tree bits) need to be saved with them.
/*
eg
code1->save(tree1, "byte_code");
*/
voodoo::vm* vm = new voodoo::vm();
vm->add(code1);
vm->add(code2);
vm->add(code3);
// for linking and setting up super objects
vm->add(tree);
vm->link();
//--------------------------
// can add code while the vm is already setup (will complain if you try to add
// methods to already existing objects)
voodoo::parser* parser = new voodoo::parser();
voodoo::tree* tree4 = parser->parse("example/test4.voodoo");
// make a copy of the tree so the code can be compiled to it.
voodooo::tree* tree = new voodoo::tree(vm->tree());
tree->add(tree4);
tree->merge();
voodoo::code* code4 = tree->compile(tree4);
vm->add(code4);
// need to add the new tree (with new definitions)
vm->add(tree);
vm->link();
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Designing the api for a scripting language
October 08, 2004 09:45 PM
I'm just wondering if anyone had any ideas for how to design the bit of a scripting language that c++ sees?
My scripting language has a few things that it needs, I'm looking for a nice simplistic easy to understand api.
The language is object orientated, and I've read that one of the things is that scripting languages shouldn't be object orientated - but I really like object orientated, and well, it's my language.
With that out of the way, my language doesn't need to know about other parts of it (like how c++ needs header files) so compilation is a little trickier. Also I have (perhaps haphazardly) decided to have the ability to have object definitions spread over multiple files, each file can add something to the object (like an interface, method, property - anything).
I can take a file and generate a tree from it... easy. Then I need to gather up multiple trees and merge them together. But in this process it could be found that:
a) The first tree has inconsistencies within itself (two methods with the same name)
b) One of the additional trees could have inconsistencies with the first tree
c) Two of the additional trees could have inconsistencies
d) An addtional tree could have internal inconsistencies
It is also important that I 'remember' the original trees - so I can compile each file separately, but I need the merged tree to do the compiling.
It would be nice to have a process that could identify which file had inconsistencies with the other file. What I used to do was at each level of the tree (package, class, interface) just move the leaves (tree analogy) into the other tree. Then with an extra pass, the tree gets merged, and problems can be identified.
It is really easy to get a lot of trees and add them together. Then merge them, but if a problem happens I don't know what file is the problem. The api has to let the control code know what file is a problem and tell the user about it. This also leads to another problem, it would be good if in some situations the parser to print an error - and quit, other times it would be good for the parser to print an error but return to the control code and even other times it would be good if the parser did nothing (in a game engine for example).
I was thinking about being able to set optional error handling, that by default the parser handled the errors, but if set right the calling code could handle them.
I've written up some sample code (well it actually compiles at the moment, but is just function stubs). I almost forgot to mention, the api has be be able handle adding code dynamically, after the initial code has been setup. The additional code cannot modify objects that are currently instanced, most of the time the additional code would have to be a whole new object.
Is this a good start, can anyone see problems with this?
This code would be using the default error handling (parser prints error, then quits) this would only be suitable for a command line program.
A little about the language voodoo.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
