Log in

No account? Create an account
Parsers in MUDs? - Mud Coders Community

> Recent Entries
> Archive
> Friends
> Profile

November 29th, 2005

Previous Entry Share Next Entry
10:12 am - Parsers in MUDs?
Just as a quick question, when people write muds, do many people ever use lex and yacc (or derivatives of them) for their parsing?

Is there a reason why you wouldn't want to? Like too difficult, or just troublesome to extend? Or some reason I'm missing totally?

Basically my one experience of a mud codebase was various version of AwakeMud (a derivative of circle which is a derivative of diku) which seemed to just write a flat parser in c... is this likely to be the rule or the exception for most muds out there?

On a total sidenote: when I first joined I mentioned an idea of writing a codebase in python, now it looks like it's entirely possible that I'll be able to use that idea for one of my CS projects this year.

(7 comments | Leave a comment)


[User Picture]
Date:November 30th, 2005 06:01 pm (UTC)
I've played with Flex (extended lex) a bit and it seemed good, even easy for the most part although I didn't give it a proper trial. Plain lex should also be good, but it might be easier to handle mutiple input streams with flex.
[User Picture]
Date:December 1st, 2005 02:57 am (UTC)
Ah, yeah... but thing is, I probably won't be writing it in C. So I'll be heading towards PLY ( http://www.dabeaz.com/ply/ply.html ) for my parsing needs.

The main reason I'm asking is I'm wondering if this stuff is generally overkill, or is it a good way to approach things if I'm likely to need to expand what I need to parse on a regular basis?
[User Picture]
Date:December 1st, 2005 06:08 am (UTC)
I've never used PLY, nor have I used yacc or bison at all so I guess my knowledge runs out here, sorry.

In general terms, what is overkill depends on how good you want your parser to be. SMAUG uses a fairly simple home-brew parser, and that parser's never got beyond "fairly primitive" to my eyes. They've made some improvements in version 2 used by RoD, but those improvements only apply to one or two commands so personally if I was writing a codebase I'd look into anything that might be more powerful. I am very fussy about human-computer interaction though. :)

The other thing I do is trade off the difficulty of understanding the documentation versus that of writing my own code. If it looks easy enough after half an hour of reading then I'd use PLY, but if not Python's quite powerful in string work, I'd certainly consider writing my own parser in python.
[User Picture]
Date:December 12th, 2005 11:04 am (UTC)
I know that Python is good with string work, but would it be able to tokenize strings the way that the yacc module in PLY would want to see them?

I figure one way it would come into its own is that you could parse things like emotes quite well. Well, you could parse lots of commands quite well, but an example would be an emote.

A basic example would be the emotes 'slap' and 'yawn'. Slap obviously needs an operand. Slapping on your own wouldn't make much sense. And yawning doesn't need an operand.

If the lexer determines what sort of emote that something is - i.e. if it's an emote that requires one operand or no operands, or as many operands as you can fit, you can then start writing a grammar that'll parse those.

i.e. if you have the tokens SOCIAL0 for no operands, and you have SOCIAL1 for one operand and SOCIALN for a multiple-operand (i.e. with no bound) emote you can then start writing grammars that recognise such things. A very loose (pseudo-code example - that I haven't bothered to normalise) might be:

SOCIAL0: emote($0); // Just takes the token 

SOCIAL1a: // Do whatever with this stuff

SOCIALNa: // do something with the n-operand emote.

I dunno, if I get as far as alias parsing in the academic version, I reckon it could come in very handy.

Anyway, I'll keep ye updated.

> Go to Top