Jaco van Iterson pounded furiously on the keyboard: > On Tue, 31 Oct 1995, Mark Coletti wrote: [...] > > 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. :) > ... 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. Sometimes the first match is not what the user might want or expect. What might be better is to use emacs style disambiguiting -- if N commands match the currently typed command, display a list of N possible completions. This doesn't imply that user must enter complete commands, merely that only enough characters to make it unique be entered. Again, this is just an idea for the New Improved Parser. (And, again, I'm concentrating my efforts in other areas of the code, anyhoo. ;) > > Conflicting command syntax is a sign of linguistic ambiguity, which > > is a badism. > Wake up, all languages have this. I'm a bit skeptical about the validity of your statement. In any case, as discussed in a previous message, certainly some reduce/reduce or reduce/shift errors might be expected to crop up while generating a parser for a given grammer. This may not be so heinous a crime if you're expecting it. If these warnings are generated unexpectedly, then you need to investigate the cause -- your grammer might just have a hidden linguistic flaw. [...] > > 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 [...] > What about making north, west, etc. accept an argument. That's what I'm talking about. I didn't see a clean way of neatly splicing in arbitrary, optional arguments for pre-existing commands. > > 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 [...] > Be careful not to change things that you don't know into things that you know > but are not better. 1) I know the current parser is bad 2) I know that a lex/yacc-based parser will probably be better > > Although CircleMUD has its good sides, it needs some basic things done > > first before new features are added: [lengthy grocery list deleted] > 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. I knew anecdotally what lex and yacc were and how useful they could be long before I started to learn how to use them. A few colleagues at work wrote a command parser for a GIS that was written and tested in just a couple of days. Some of the folks at USGS wrote a parser in lex/yacc to read a file written in a specialized language in just a matter of days, too. There are other cases I can think of, too, and in every one lex/yacc was helpful. This is _not_ to advocate lex/yacc as the ultimate panacea for parsing problems, but I just wanted to relate that I didn't happen to just read the O'Reilly _Lex & Yacc_ bug and go "Keen! Now what can I use this in? Hmmm." =8-) > Using lex and yack to change the grammar would be a good idea > though, making the mud understand more about english. Someone mentioned the danger of trying to make this like ELIZA -- that is, to add sophisticated natural language parsing that would (probably) obsfucate things both from a user and maintainer perspective. (Although, ELIZA is fundamentally a series of cheats and doesn't really do anything in the rocket science category.) That's why I'm going to spend some time designing the grammer before even _thinking_ about implementing it. > what exactly are sentinals and what are opaque types? Opaque types I described in detail in a prior post -- I can zing another copy to ya if ya like. :-) Sentinals are these types of things: #ifndef __FOO_H_ #define __FOO_H_ // header file stuff #endif They keep header files from being included more than once. They should be relatively easy to add to the existing header files, and will probably be one of the first things I do. > is it easy to use lex-yacc to create data structures (for world loading)? I guessume you're talking about writing a parser to read world/object/shop type files -- yepper, that should be relatively easy to do. No, really! Honest! :) > Jaco Mark -- Mark Coletti | DBA Systems, Inc. Fairfax, VA mcoletti@clark.net | United States Geological Survey http://www.clark.net/pub/mcoletti | Office of Standards & Technology Line noise courtesy of NSA wire-taps.
This archive was generated by hypermail 2b30 : 12/07/00 PST