[MUD-Dev] Storing tokens with flex & bison

cg at ami-cg.GraySage.Edmonton.AB.CA cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Jan 2 10:58:02 CET 2000


[J C Lawrence:]

> I've used recursive decent parsing for all my micro-languages for
> the simple reason that I was never willing to confront lex/yacc or
> their derivatives and I'd done all my interesting language work
> before I ran across PCCTS et al.  Recursive decent parsers are easy
> to do, easy to get reasonably right as long as your language is
> regular, and of course horrible to optimise or put a proper VM
> under.  That all said, I agree, given current CPU speeds, for
> hobbyest games and typical activity rates on your server (say a few
> hundred users etc) there is little reason to not use a recursive
> decent parser.

I'm in a similar situation - I did my first language before I'd heard of
lex/yacc, let alone ANTLR/PCCTS. So, I've never learned any of those
tools. This includes doing an ANSI C compiler at work several years ago.

JCL: why do you say recursive descent makes it hard to put a VM under a
language? Lexing/parsing is pretty independent of execution. My AmigaMUD
system uses recursive descent for its programming language, and that had
no effect on being able to put a byte-code machine into the system. It
had never occurred to me to even think about any effect. Hmm. Perhaps
I'm misparsing the conjunction in your sentence?

Byte-code execution really only makes sense, I believe, for a strongly
typed language. If run-time checks and conversions are needed, they will
likely cost far more time than the basic interpretation of the code, and
so going to byte-code instead of staying with something more direct, could
be a waste of time, in that byte-code won't speed execution up much.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list