November 29th, 2005
|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.
|Date:||November 29th, 2005 10:40 pm (UTC)|| |
I know for fairly sure that the original LPMUD 2.4.5 used bison for some of the parsing stuff. But that was in like, 1991.
|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.
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?
|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.
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.
About your side note, how is your Python going? I read a lot of ideas made for using Python but find little about where it ends up. I'm working my way through a novice's version of a MUD server written entirely in Python and I'm wondering if you are already getting into your own.
Well, I never managed to get it off the ground over the past while. When I was in college, I was too busy concentrating on other things (which I got marks for), and when the summer came I was too busy job-hunting, and when I did get one, it took too much time.
But I have a fairly solid idea of how it'll work.
And now, I've emailed my lecturer about possibly doing it as a project for the next semester, which means that myself and 3 others will be able to work on the project and getting it off the ground.
So it's an ideal way for me to work on it, to set aside time (because it'll be my project), and it'll go a way to earning marks in my final grade. Now I just need to convince people that it's a good project to work on.