On Fri, Mar 9, 2012 at 16:58, Rhys Ulerich <rhys.ulerich@gmail.com> wrote:
Fair enough, I probably wouldn't want to give someone a full Python interpreter inside a video game. Still, I suspect locking down a full interpreter is easier than inventing, implementing, and fully testing a one-off language with reduced capabilities.
It depends on the context. In mine, I want to provide a full scripting language VM to the game developer. I also want (and that is "rare") to let the user play with another VM that have a specific purpose (and is allowed only some libraries of the scripting language). It IS useful to be able to use a scripting language in a command line system (whatever the purpose - I have several different ones but I'm in a very special case I think). But it is non-sense to make a scripting language be the command line system implementation.
Especially because the capabilities will likely need to grow in time as your users become more advanced. It's nice to one day say "Oh yeah, that's actually Python" rather than say, "Oh yeah, we need to re-invent something functionally equivalent to Python but which is expressed in our in-house language."
Then just provide a command that is "modal" and called (from the code) at the beginning of the console. It would only send expressions to the scripting language VM and return it's result. Make sure the VM is loaded with the wanted libraries and other tools that the user might need. Don't bother the console system, it should only be an "interface", nothing more. That is, in my experience, the way to get it modular enough to make it useful to a lot of people. Joël Lamotte