Looking for suggestions/advice

[Rodney Somerstein]

>Yes, by all means write an interpreter! It's not that hard and fun 
>too, with no script limits. I did this in Hypercard once. I needed 
>to munge huge text files for translation between databases, so I 
>created an 'action processor' with a simple language that could save 
>its code as a resource in the stack.
>
>Just make it human-readable, and you can even use some of the 
>'forbidden words' used for Transcript. Most of your 'interpreter' is 
>going to consist of CASE or IF-THEN statements.  You're going to 
>need some time brainstorming the structure --but are basically just 
>redirecting your new commands to rev handlers. Error checking and 
>validation is up to you. And of course since you're writing it, it's 
>extensible at all times.

Thanks Stephen. This is just the kind of feedback that I was hoping 
for. I know there are general purpose tools for writing parsers 
outside of the Rev world. I've seen mentions of things like Lex and 
YACC over the years. I have no idea how to use such tools, though. My 
concern with your approach is two-fold:

1) It seems to me that as the language grows it will get 
progressively slower if I'm just continually adding IF-THEN 
statements or adding to one large CASE statement. Again, I'm looking 
for pointers toward easy to understand but better methods for doing 
this.

2) Error checking and validation is again something that I know have 
been generalized outside of Revolution. If I can use something that 
already exists to help facilitate this, then so much the better. That 
would mean it is much quicker to add new commands to a language.

I am considering using XML as the base for the language. I can use 
tags which can be validated by a DTD or Schema. Arguments can be 
handled via attributes for the tags. Revolution already has built-in 
tools for helping with this. I only see this approach working for 
people designing game modules. Someone who wants to write a game 
player AI would definitely have to learn Transcript or whatever 
scripting language I ultimately use.

>This also has added security, as you completely control what happens 
>in your world, as opposed to using the rev script system - and 
>message path - to interpret your scripts.

I'm not that concerned about security. As I mentioned in my 
previously lengthy message, there will have to be a program specific 
command language for creating games. This will be a very secure 
language. I don't want the average person to have to resort to 
learning a more generic language such as Transcript, Python, or Ruby. 
However, I think that I need access to such a language for people who 
want to help me extend the system or who start chafing at the 
limitations that I impose on them due to my implementation. I want to 
design as wide open a system as possible for people to extend. I 
don't want to just tell people that if they want to implement their 
favorite game, they have to fully learn a complete programming 
language.

However, I've just realized that if I do use a language such as 
Python or Ruby for the scripting environment, the command language 
could be supplied as a library of methods for that language. People 
could then simply learn the basics of the programming language and 
use the library of commands that I supply for most of what they want 
to do. Only people who want to go beyond what is built in would need 
to learn more than the basic structure of the language in question. I 
like Rev/Transcript and would love that to be the environment I 
implement in. Due to the artificial restrictions placed on 
stand-alone applications, that may not be viable without requiring 
people to purchase at least a DreamCard license.

As I've been typing this message it seems more and more that creating 
a library of commands, rather than a language itself, might be the 
better way to go about implementing this. If I do so, that might 
eliminate Revolution as a real consideration. If Rev could at least 
generate a script from a command file that I imported, then I could 
work around this. More sophisticated users would just use Transcript 
in DreamCard and call the scripts that implement those commands. Less 
sophisticated users would simply construct command files. I'm 
concerned that the 10 line limit on scripts created in standalones 
might be the real killer for me here. Without the way to generate 
scripts of arbitrary size from a command file, I don't see any way of 
connecting the two worlds. If someone wanted to go beyond the command 
language I provide, they would have to jump into the implementation 
language completely and ignore my cumbersome language parsing. I'm 
not sure how much of what I had already done could be made easily 
reusable for people who want to go beyond the basics.

-Rodney