Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-ngp.UTEXAS Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!ut-ngp!oacb2 From: oacb2@ut-ngp.UTEXAS (oacb2) Newsgroups: net.lang Subject: Re: Reading programs left-to-right. (LONG) Message-ID: <2236@ut-ngp.UTEXAS> Date: Mon, 12-Aug-85 14:47:27 EDT Article-I.D.: ut-ngp.2236 Posted: Mon Aug 12 14:47:27 1985 Date-Received: Wed, 14-Aug-85 01:49:51 EDT References: <6571@boring.UUCP> <10984@rochester.UUCP> Organization: UTexas Computation Center, Austin, Texas Lines: 38 > I will bet that there are some historical reasons. First, primitive parsers > were in desperate need for clean anchor points. So, the significance of new > lines in Fortran. Correspondingly, they wanted to be able to decide about > the statement type with little or no context. I find it difficult to believe this consideration had much to do with writing a = b + c rather than b + c = a in FORTRAN. In fact, in a number of places (e.g., having no reserved words) it almost looks like the designers went out of their way to make it difficult to parse. For example, after scanning call it(5) we still don't know what kind of statement we're dealing with. The line could continue call it(5) = 7.0 It's incredible that anyone worried about making it easy to identify statements would design a DO statement that cannot be identified until the comma between the inital and ending value is scanned. FORTRAN is full of things like this. It's an extremely easy excercise to write a FORTRAN program that a human finds almost unreadable just by using keywords and spaces creatively. I'd guess that the order of assignment statements came largely from the usual practice in mathematics of writing equations which have one side a single variable with the variable on the left. -- Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550