On Tue, 31 Oct 1995, Mark Coletti wrote: > > As to being complex, I heartily disagree! In this case, the possible > permutations for "north" commands are explicitly stated. Nowhere in the 1500+ > lines of ``interpreter.c'' did I see a way to automagically come up with > shortened prefixes for commands. And, yet, in four lines I've explicitly > done so in a way that, to me, is intuitive. :) > I don't understand this, if you add the commands in alphabetical order in interpreter.c (or in any order for that matter) shortened prefixes automaticly work giving you the first match. So n no nor nort and north all work while you don't have to specify them explicitely. > Conflicting command syntax is a sign of linguistic ambiguity, which > is a badism. > Wake up, all languages have this. > It might be (sorta) easy to add new commands to the command symbol > table, but it's not easy to _change the grammer_. > Use lex-yuck only for that then. > For example, when I was dreaming up the earlier examples, I > arbitrarily decided to extend the example grammer to allow an optional numeric > parameter that specified the number of moves to make in a given direction. It > took just a few minutes to add in the NUMBER token and its support, and to > extend the yacc grammer definition to accomodate specifying the number of > moves. I've looked through ``interpreter.c'' and I don't know where even to > begin to make the necessary changes to do the same thing. :-\ What about making north, west, etc. accept an argument. > > In short, adding new keywords and their respective support functions > seems to be relatively easy in CircleMUD; modifying the command line _grammar_ > is a different story altogether. > Keep the easy things and only change the difficult things. Just change "fill canteen with the water from the fountain" to "fill canteen from fountain" and let interpreter.c do the rest. > Besides, it's safe to say that more programmers understand lex and > yacc than there are programmers that know how the CircleMUD's parser works -- > if the parser were written using lex and yacc, it's more likely that newbie > programmers would be able to get up to speed on the code as they're more > likely to have some familiarity with lex and yacc. Anyhoo, they can always > run down the street to the local Borders or whatever and get a lex and yacc > textbook; they can't do the same for the CircleMUD parser. > Be careful not to change things that you don't know into things that you know but are not better. > Although CircleMUD has its good sides, it needs some basic things done first > before new features are added: > > o Makefile should not have explicity dependencies; ``makedepend'' or > gcc -M should be used to automagically generate them > o Makefile should rely as much as possible on implicit pattern > matching rules to eliminate redundancy and complexity > o Add header file sentinals > o Reduce dependency on pre-processor wherever possible > o Simplify header files by moving as much as possible to > implementation files > o Introduce opaque types to reduce code complexity > o Rely on lex and yacc for command line parsing > o Re-visit the command language grammar and its implementation > o Rely on lex and yacc for world, zone, shop, and object file parsing > o Re-visit the world, zone, shop, and object file language syntax > They all sound like good ideas, only you're a bit to fond of lex and yacc. It seems to me that now you mastered lex and yack you want to use it where you can, even if it doesn't change how the mud works (in a users view) and doesn't make it easyer to change things. Using lex and yack to change the grammar would be a good idea though, making the mud understand more about english. I have a few questions: what exactly are sentinals and what are opaque types? is it easy to use lex-yacc to create data structures (for world loading)? Jaco
This archive was generated by hypermail 2b30 : 12/07/00 PST