Talk:One-pass compiler

Really Not One Pass

I'll note that there really is no such true thing as a one pass or single pass compiler, because the text that is passed by is stored eventually in buffers to analyze again (tokens etc.) and the whole idea of a true one pass compiler is almost a lie, by what people consider one pass compilers today. There are definitely less passes possible with compilers, but it's all just text being thrown around into buffers... and the buffers are passed over individually after the a major consumption is done - and all these little sub passes within the buffers mean we are going over the same data more than once. During the major consumption of the source file, there are little sub passes on temporary buffers of text that are munged around while passing over - and copying part of the source file into a little buffer and going over this buffer is technically destroying the notion of "single pass". Especially if lots of little buffers are checked, it adds up to a total of more than one pass. I may be retentive for noting this, but using Visual thinking I have never once seen a parser in my mind as a true "single pass" or "one pass parser".

I think the terminology in computer science could be improved to identify parsers which go over the data much less than other parsers - but calling it "single pass" or "one pass" is very misleading, especially to those who don't actually know a lot about parsing and are prone to believe this fraud ;-) Some parsers definitely go over the data in several major consumptions over and over again, but there really isn't a true one pass parser other than an UpperCase or LowerCase function. LFiveZeroFive (talk) 15:17, 8 April 2008 (UTC)

"True" "one pass" might be only regular expression (if you forget that "looking back" is done by traversing states - very abstract or by looking at state variable;). Expression with braces needs memory (due to precedence) and thus looks back on what it has previously read ;) I agree with "One pass" being very misleading. "One/single representation" migh be better, even though ... or "One abstract syntax three is enough" :) ca1 (talk) 09:03, 13 May 2008 (UTC)

Splendid. You have tried to redefine a generally accepted term of art in the talk page of a Wikipedia article. We are all enlightened. However, Wikipedia is not the place for original research. HughesJohn (talk) 23:01, 30 November 2011 (UTC)

I'll just note that the original comment is incorrect. Peter Flass (talk) 22:19, 15 April 2012 (UTC)

Examples

I added a few examples that were identified in their Wikipedia articles as "one-pass compilers." I'm sure there are many more. Peter Flass (talk) 22:20, 15 April 2012 (UTC)

Miss The Point

The idea that a compiler with a parser than can look ahead a couple of tokens isn't a true single pass compiler is misguided at best and completely misses the point. Yes, a compiler is still single pass if it has to wait until it reaches the end of a number to see if it has a decimal point or even if it waits to get to the end of a function before it starts generating code. Single pass compilers like Turbo Pascal played an important role in making high level languages available at a time when a megabyte was still more memory than most people could afford. Their simple design made those compilers easy to develop, allowed them to fit in main memory, and produced fast compile times, if not always fast code. That should be the focus of the article rather than trying to make a case about how if your parser has to push a few tokens or even a few statements on the stack that it's not really a single pass compiler. The Arcadian 98.169.58.20 (talk) 02:48, 7 December 2014 (UTC)

It is not just "look ahead a couple of tokens", because an arbitrary amount of source code may be spanned by a statement's components, as with a "case" statement, so some sort of "go back and fix stuff" is forced. This is the point of "Really not one pass", though I wouldn't say it is text in buffers that is being messed with. Jigging about over one symbol and its following symbol (for <=) or for a few symbols (names and numbers) bothers no-one with regard to single-pass or not, but that is one end of a wider discussion. Similarly, an internal data structure is accepted as a representation of portions of the source during compilation, without declaring the compiler multi-pass. I was attempting to show the difficulties that would confront anyone preparing a compiler for the usual sort of language, that would soon wreck any literal notion of steadily generating complete code as output while steadily reading the input source. Thanks to N. Wirth, Pascal has a clean design and he intended writing a Pascal compiler in Pascal as a teaching aid. As for memory limitations, the IBM1130 Fortran compiler had to run on a system that may have no disc storage and only 8k memory. Although it truly read the source file (a deck of cards) once, it represented the source in memory, and this representation was massaged by well over a dozen "phases" of the compiler, loaded one after the other, on the way to generating the object code. This separation of tasks led to a very reliable compiler, at the cost of multiple passes over the source representation. By contrast, the assembler on a discless system did indeed require that the source deck be read a second time. Turbo Pascal's compiler was fast because it was written in assembler and great attention was paid to speed. NickyMcLean (talk) 11:08, 14 December 2014 (UTC)

Lexical Analysis

According to IBM and other sources, this lexical analysis scanner is referred to as Lexical Analyzer and not Analyser. Nsbfrank (talk) 15:44, 14 December 2023 (UTC)

It probably depends on which side of the Atlantic Ocean you are on. The general rule in Wikipedia (WP:ENGVAR) is that an article closely tied to a particular country should use the spelling etc. for that country, or use country-neutral words if possible, otherwise use the spelling of the original author. Murray Langton (talk) 18:09, 14 December 2023 (UTC)

Oh great @Murray Langton, I totally see your point. Nsbfrank (talk) 10:49, 15 December 2023 (UTC)