Looking for suggestions/advice

[Rodney Somerstein]

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