?

Log in

Parsers in MUDs? - Mud Coders Community

> Recent Entries
> Archive
> Friends
> Profile

November 29th, 2005


Previous Entry Share Next Entry
tearsofzorro
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)

Comments:


[User Picture]
From:tearsofzorro
Date:December 12th, 2005 11:04 am (UTC)
(Link)
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 -> SOCIAL1 OPERAND
SOCIAL1a: // Do whatever with this stuff

OPERANDSTRING -> OPERANDSTRING OPERAND | OPERAND
SOCIALNa -> SOCIALN OPERANDSTRING
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
LiveJournal.com