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
_______________________________________________
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
