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