Re: Why separate the lexer and parser?

In case it hasn't been pointed out already, much of the modularization of
SW conceived, designed or written before ~1975 was driven not by elegance
or convenience, but by the @#$%^&* small memories and/or address spaces of
machines of the time. Some apparently have used hindsight to justify this
modularization on other grounds, but it was a kludge then, and remains a
kludge now.


The IBM 1401 Fortran compiler had ~100 (one hundred) passes in order to
compile Fortran in to 1401 machine code. It stored the program in memory
and passed the code of the compiler against it from a tape drive. Given
the technology of the time, it was a relatively fast solution to the
problem. I've been waiting for someone to claim that this is the _best_
way to organize a compiler on today's machines. :-)


The problem with tools like lex/yacc is that they beg to be used, and
_are_ used, 100X more often than they ought to be. Do we really need
10,000 different formats for the various parameter files in computer
systems? (Perhaps finite state machines and parsing techniques should be
banned from CS undergraduate curricula, so that students could actually
learn how to be part of the _solution_ to computer problems, instead of
becoming additional parts of the _problem_.)


            Henry Baker
            Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.