Re: Using lex and yacc for parsing

From: Wout Mertens (Wout.Mertens@rug.ac.be)
Date: 11/02/95


On Wed, 1 Nov 1995, Mark Coletti wrote:

You /really/ like long posts, don't you? :)

> Wout Mertens pounded furiously on the keyboard:
> 	Well, now that you mention it, I did this a few days ago!  =8-)
> ----->8 snip snip snip 8<------
Kewl! Thanks!

> > > 	o Reduce dependency on pre-processor wherever possible
> > Duh? Why?
> 
> 	The pre-processor is used to include files, to conditionally
> compile code, and to define macros.  I don't quibble with the first
> two points, but the last one has some issues that could be raised.
> (Which are admittedly mostly trivial.  :)
> 
> 	Macros are mostly used to define constants.  With the advent
> of the ``const'' keyword in ANSI C, it's really a better idea to
> define constants as real variables that have ``const'' pre-pended to
> them.  The constant now is located in the symbol table, whereas it
> wouldn't if you had defined it as a #DEFINE.  This makes debugging a
> bit easier.
And the code larger :) (Hmm, not that much tho.... Ok. You have my 
blessing on this one :)

> > > 	o Simplify header files by moving as much as possible to
> > > 	  implementation files
> > You mean things like AFF_INVIS should not be in structs.h but in
> > mudstuff.h?
> 
> 	Actually, there are a lot of things that could be done to the
> header files:
<snip> 
> 	o global header files are Evil!  Break them up into separate,
> 	  meaningful header files.
I would *love* to see you transform structs.h to something less global :)
Ok, a few structs can be moved to other places, like the save structs, 
but still...

> > > 	o Introduce opaque types to reduce code complexity
> > struct char_data -> char_data? or what do you mean?
> 
> 	Gak!  I _knew_ somebody was gonna ask me about that!  8)
<object oriented stuff deleted>

Thanks for typing it out :)
I wonder if someone will ever convert the mud to c++? Must be a hell of a 
job.

> > > 	o Rely on lex and yacc for command line parsing
> > Why? Isn't it better to make our own parser that will take things like "P s"
> > as a format id for a function expecting 1 player and a string, that will 
> > process errors and such?
> 
> 	Nope!  I would rather write a parser that used lex and yacc
> (or any of their progeny).  That way I could create more flexible
> syntax that would probably be parsed with fewer errors.  Why re-invent
> the wheel when there's one already around that works extremely well?

Weeell, there was Stroustrup I believe who was feeling sorry for himself 
for using yacc and lex for his compiler... (Don't quote me on this! I'm 
not sure it was him. Someone was sorry anyway :)

I think that they are a bit more difficult for decent error checking...
I could be wrong tho.

And then there's still the auto-abbrevving, which I think is a very good 
feature, that will be lost...

*waves*,

Gekke Eekhoorn of BUG.



This archive was generated by hypermail 2b30 : 12/07/00 PST