Are Lex and Yacc still the state of the art 20 years later?
They still work perfectly fine, though, ANTLR is pretty great. Having learned both, I would hesitate to switch back from ANTLR.
Plan to throw one away
11–20 of 88 posts
Re: Plan to throw one away
#12This makes me want to write a JS interpreter... Sweet read!
A simple ES3 interpreter is pretty easy, particularly if you just go for 'the good parts' (plus basic global objects).
I can highly recommend mpc[1] if you do, it's a really amazing library for parser combinators in C. I was never much of a fan of yacc/lex (perhaps out of my ignorance of BNF). With yacc/lex I always felt like I had to have my grammar all planned out (which if you implement JS I suppose isn't a problem) before I could start developing and it was very hard to work incrementally. mpc is very flexible and since it's just a C library I find it a lot easier to iterate with.
Re: Plan to throw one away
#13Cool read, however, I feel the need to point out that 20 years ago, javascript in the server wasn't "too soon", it already existed. In 1995 Netscape had the Netscape Enterprise Server[0] that ran javascript for server-side scripting. Actually, the two books I used, back in the day, to learn Javascript was the client- and the server-side javascript guides published by Netscape. [0] https://en.wikipedia.org/wiki/Netsca…
> javascript in the server wasn't "too soon", it already existed
Those two things aren't necessarily in conflict. Netscape's server wasn't exactly a roaring success. What really made Javascript-in-the-server work was a Javascript JIT engine (v8) that actually made Javascript very competitive compared to traditional server side scripting languages. So given that there did not exist a Javascript JIT engine back then, maybe it was too soon.
Re: Plan to throw one away
#14Are Lex and Yacc still the state of the art 20 years later?
Be prepared to just use the generated tables and forget the generated code: The generated code is not so great if you have an event driven environment: I mean I want to push 50 bytes into the compiler, instead of having it request the next input character. This means it's not so great for a repl, unless some other pre-parser gives complete translation units to lex/yacc. I think Yacc has a pretty primitive conflict re…
In terms of ease of use, Parser Combinators beat most Parser Generators. (For absolute speed, Generators might still beat Combinators.)
Re: Plan to throw one away
#15> The failure to store a represention of the parsed code was disastrous because it meant that in order to evaluate an expression or statement for a second time, the engine had to parse it a second time. Ha! They must have learned how to write an interpreter from Herbert Schildt: http://www.drdobbs.com/cpp/building-your-own-c-interpreter/1... [1989] In this piece of amusement, the Little C program is a giant null-term…
Didn't PHP also used to use the position of a fileseek as the instruction pointer?
Re: Plan to throw one away
#16Cool read, however, I feel the need to point out that 20 years ago, javascript in the server wasn't "too soon", it already existed. In 1995 Netscape had the Netscape Enterprise Server[0] that ran javascript for server-side scripting. Actually, the two books I used, back in the day, to learn Javascript was the client- and the server-side javascript guides published by Netscape. [0] https://en.wikipedia.org/wiki/Netsca…
Not long after (now) classic ASP was introduced with JScript as an option. I wrote a lot of it back then, and used JS about as much as VBScript, because I could reuse a lot of my libraries on both sides (validation in particular).
Re: Plan to throw one away
#17Earlier quoted context omitted.
Be prepared to just use the generated tables and forget the generated code: The generated code is not so great if you have an event driven environment: I mean I want to push 50 bytes into the compiler, instead of having it request the next input character. This means it's not so great for a repl, unless some other pre-parser gives complete translation units to lex/yacc. I think Yacc has a pretty primitive conflict re…
In terms of ease of use, Parser Combinators beat most Parser Generators. (For absolute speed, Generators might still beat Combinators.)
Yeah, I should try them. I remember a previous discussion about the old language SNOBOL having parser combinators as a built-in feature: https://news.ycombinator.com/item?id=10103460
Re: Plan to throw one away
#18>One thing that I had not had time to do was to write a garbage collector.
Cheat: use Hans Bhoem's conservative collector for C/C++: http://www.hboehm.info/gc/
Re: Plan to throw one away
#19Are Lex and Yacc still the state of the art 20 years later?
I don't know about "state of the art", but they are tried and true for lexing and parsing respectively.
If you are looking for something more exotic or a very specific use-case, I'd say use something like Ragel[0].
Re: Plan to throw one away
#20I find the dates a bit suspect (referenced ECMA script standard was June 1997, book was late 1996, so how did this all happen twenty years ago, just months following the official release of JavaScript in May 95?), but guess that's not the point. Maybe I'm alone, but implausible details distract me from an otherwise great story that can teach a lesson many should learn.