Thanks for the input, Dan. Can you tell me a little more about the table driven approach you were mentioning? Are doplay and playTheGame two different commands, both of which take the same arguments? Or is doplay the user command and playTheGame is the script that I would call after determining which command was issued? I'm guessing the latter is what you were explaining to me.
This approach might be able to eliminate some of my concerns with writing a parser. Namely the fact that if someone wanted to go from the simple world of creating a game module using what I provide to something more full featured they would lose the ability to use what I had written. With this approach, especially if the internal script names and external command names are the same, they could still call my scripts even though they would have to learn Transcript or some other language.
It would also eliminate the limitations of creating scripts from a standalone as I would not be doing so. I would simply be calling scripts that I had already written. It would mean that someone who wants to do *anything* more than what I provide would have to buy a DreamCard license and start learning Transcript in depth.
RBScript sounds interesting, but I have been led to believe that REALBasic doesn't work as well for non-Mac programs. Have they gotten to the point of producing great code running on Mac and Windows without having to jump through a lot of hoops? For that matter, has Rev really gotten to that point? What about Linux?
What do you think of the approach that I mentioned in another message of making the scripting language pretty much be composed of just methods/scripts in whatever language I choose? This eliminates the need for writing an interpreter altogether. I simply use the arguments passed in with the call to the method rather than parsing each line. I could provide a simple shell script for people to write their "programs". In Python this would mean the appropriate imports and such to make the game scripts available. If someone then wants to go beyond that language, they are already working in the correct programming environment.
This approach, unfortunately, would seem to rule out Rev as an environment due to the limitation of scripts that come from outside a stack in a standalone to 10 lines. Since any game that I can think of would take more than 10 lines to implement, it means that everyone would need a DreamCard license. Again, since I want this to be a free system, requiring someone to pay for a DreamCard license probably isn't feasible.
Another consideration is that if I switch away from Rev, I will need to switch to a language other than my scripting language being used to write the base application. Unfortunately neither Python or Ruby seem to offer any easy way to write standalone applications with a GUI and make the application easily deployable for non-developers. So, I suspect I would end up needing to switch to embedding Python or Ruby in Java to allow for this. Since both languages already offer Java implementations, this would be easy. I'm not sure whether Ruby is really viable, but I've heard it mentioned a lot so I have just started looking.
I will take a look at YACC. It is something that I have been aware of, though I have no clue how to use it. I imagine, as you say, that just looking at it may help me clarify how to do what I want in a language.
Thanks, -Rodney _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
