[MUD-Dev] Storing tokens with flex & bison
cg at ami-cg.GraySage.Edmonton.AB.CA
cg at ami-cg.GraySage.Edmonton.AB.CA
Tue Jan 18 20:41:00 CET 2000
[J C Lawrence:]
> > 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.
>
> Oooo! Pre- or post- ANSI? I made a stab at doing a pre-ANSI K&R
> compiler once. It wasn't pretty. Harbison & Steele's pain was not
> imagined.
Er, post. Actually I started when ANSI was still making choices. I was
really hoping for the "pointer model" for enums to win out. Drat!
> Shoving a VM under a parser when the parser was not written with a
> VM in mind is not fun. Yup.
Another thing that will vary from case to case, I guess. Worked fine
for me, and I hadn't even thought of it when I was doing the language
and the initial parse-tree interpreter.
> Certainly cases on either side of the fence can be contrived.
>
> That said: Python, Tcl, Perl, and REXX are all weakly typed, and all
> now are byte-coded. I suspect that they saw some advantage.
I'm not fully up on what the old technologies of all those was. However,
both Tcl and REXX (at least the Amiga version, AREXX) were strict
string interpreters (like ToyMUD). That introduces loads of overhead,
and going to nearly any other kind of execution model will give you one
or two orders of magnitude. How much you get from there to a bytecode
machine is, I think, the interesting question. However, since it really
isn't any harder to do a byte-code system than most of those other
interpretation systems, I guess you may as well go all the way. Well,
short of emitting native code, anyway.
--
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