[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