Why bother re-writing that much code. If you want interpreteded code, get *gasp* LPMud. > Hia, > > On Tue, 8 Oct 1996, Gary Barnett wrote: > ... > > Design Requirements: Interpreted language for rooms (and later mobs and objs) > > that would be flexible, simple to learn (and debug), and as fast as possible. > > It's possible, I have done it upto now only for mobs, rooms I have to add > later on... (meant a bit of a rewrite since it was too mob based, should have > thought first :( ) I used the compiler/scanner generators from the cocktail > toolbox because those were written for speed.... Untill now the produced > interpreter is way fast enough on our mud server. e.g. one load thousand mobs > with fight prog into room and let one go berserk.... result screen output is > bottleneck no lag because of the fight triggers. (one cheering happy > implementor feeling :) Using a parser generator makes imping the thing a lot > easier. Unless you don't know how to use them.... then it's a big problem :( > wrote the first running version of my mobprogs in about a 14 days (to > illustrate the fact that using a generator is quite handy (i didn't even > write fulltime)). > The toolbox takes also care of generating syntax error stuf complete > with line and column numbers and what it is expecting of you on the > point of the error. > For the speed requirements I used a recursive descent parser (a system > where each language construct is put in one function which calls > recursively other functions. (ok it's not 100% accurate description but > alla) In the specs of the toolbox it is stated that it can parse about > 900.000 lines per minute (on a 68020). > > > This system must allow online entry via OLC.. > > Then you'd have to write a better editor..... maybe even one using > charactermode telnet. Or find a way to glue an external editor to the > telnet connection of the user (Unix only I guess) > > > and dynamic program replacement, > > That's no problem if you got the structures a bit sorted out... > including freeing up space of old programs, variables etc. > > > so a reboot will not be required. Also a means of reporting syntax errors at > > the time of entry will be included. > > That might require using two parsers.... one for syntax checking and one > for the real executing. (ok it's possible to do it in one but that would > mean adding some means of 'dry run' mode and I don't think all those > checks would be to well for the speed of the sucker) > > > Room Program Types: <snip> > > IMHO sufficient ;) > > > Program Structure Keywords > > FOR I = ? to ? - Used primarily to step through a list of people > > EXIT to do some nasty effect to them.. or just move > > NEXT them around..or step through a list of items to > > damage them *grin* > > I didn't add loops because of the fact I used a toolbox. The if was already > quite a dirty hack but loops wouldn't be impossible making a for would be > safe I guess... using a while (or something like it) might not be a good > idea. What if a prog writer screws up and a mob/room/prog ends up in a > endless loop in which it loads thousands of mobs in a room (or something > extremely funny like it :) (though done in a for it might be quite an > indigestion for your mudserver too) > > > INTERVAL - Used to set how often the program runs. (one second granularity) > > good idea > > > RETURN - Done.. End the program. Not required at the end of the program. > > RESTART - Clear all local vars and start at the top. > > Tricky using a recursive descent parser..... (can be done but loads of checks > all over the place, altough.... I'll go see the code i guess :) ) > > > RUN - End this program, and Run another room's room program. > > There's a limit on this I hope or something to prevent progs running > eachother indefinitely. > > > CALL - Run another room's room program, then restart this > > program when it finishes (this will clear local vars) > > Clearing local vars?? i guess that wouldn't be practical... Also a user > of the language might think of it as very strange.... Again the prog a > calls prog b calls prog a problem.... > > > Commands > > For the commands I used the command interpreter (this is also the reason > why I have to do a bit of a rewrite :( (command_interpreter needs a > char_data <sigh>) For mobs it works beautiful for rooms it would really > suck.... > > > (C style +=, -= is only supported in the SET command) > > With parser generator real easy to add ;) > > > INFO - Send a string to the INFO channel. > > Maybe add a prog channel (for all kinds of errors (only to imps)) > > > Data Structures: > > MOBS[] A list of the mobs in the room. > <snip> > > > > CHAR[] A list of all players in the room. > <snip> > > (ok it's a very small change not worth mentioning almost but call them > MOB[] and CHAR[] or MOBS[] and CHARS[] (I personally hate such small > inconsistencies in languages - ok sue me for it ;) ) > > I missed these: > > .MONEY -- (RW) mob/PC's money > .BALANCE -- (RW) mob/PC's bank balance > > > WOBJS[] A list of all the objs the event causer is wearing. > > EOBJS[] A list of all the objs the event causer is wearing. > > Why not MOBS[] or CHAR[].WOBJS[] ? so you'd get > CHAR[].WOBJS[] -- worn objects > -- with indices names of wear positions > > eg: CHAR[CAUSER].WOBJS[WIELD] > > CHAR[].IOBJS[] -- inventory objects > > > Temporary Variables... used for program scratchpad and text output. > > I used 'complete' variables so you'd declare some variables at the start of > the prog and you'd use them by their respective names (construction with > hashtable). I imped an int and a string type. even made it so that all > variables for a mob are shared over their triggers progs, and the values are > remembered during consecutive trigger calls... > > > Restrictions on code. > > > > 1) For Loops. > > a) Cannot be nested > > IMHO impracticle... > > > b) Cannot be inside of an if/then construct. > > Why? > > > 2) If/then/else/endif statements. > > a) Cannot be nested. > > Again impracticle.... (IMHO that is...) > > Hope I said somehting usefull in this load :) > > (my replies to replies to this might take some time for faster replies > send a cc to klarenj@cs.utwente.nl) > > Grtnx GrimReaper > aka > -----+++++*****************************************************+++++++++------- > - Ric Klaren - j.klaren@student.utwente.nl - ia_ric@cs.utwente.nl ------------- > -----+++++*****************************************************+++++++++------- > ``Why don't we just invite them to dinner and massacre them all when > they're drunk?'' > ``You heard the man. There's seven hundred thousand of them.'' > ``Ah? So it'd have to be something simple with pasta, then.'' > ------------------------------------------------------------------------------- > From: Interesting Times by Terry Pratchet > -----+++++*****************************************************+++++++++------- > > +-----------------------------------------------------------+ > | Ensure that you have read the CircleMUD Mailing List FAQ: | > | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | > +-----------------------------------------------------------+ > * Classic@Cloud9.net * tpedersen@kraft.com * * http://www.cloud9.net/~classic * * visit Darklord MUD at pody.westnet.com 5000 * +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST