Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site rpics.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rpics!weltyrp
From: weltyrp@rpics.UUCP (Richard Welty)
Newsgroups: net.lang
Subject: Re: Re: Reading programs left-to-right.
Message-ID: <161@rpics.UUCP>
Date: Tue, 13-Aug-85 22:21:52 EDT
Article-I.D.: rpics.161
Posted: Tue Aug 13 22:21:52 1985
Date-Received: Sat, 17-Aug-85 05:49:00 EDT
References: <6571@boring.UUCP> <10984@rochester.UUCP>
Organization: RPI CS Department, Troy  NY
Lines: 40

> 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.  This appeared in the form of
> keywords or reserved symbols appearing as far to the left as was convenient.
> As examples, BASIC's 'let' and FORTRAN's 'call' (or the mysterious commas,
> mostly optional and normally forgotten, in 'do' and both the computed and the
> assigned 'go to's).  (Anecdotally, I was once bitten by a compiler that wouldn't
> take this:
> 
>       identifier
>      *=  atrociously long Fortran expression
> 
Actually, many early compiler were completely ad-hoc (no formal model was
used).  For example, the Honeywell Series 16 Compiler expected to know the
statement type after parsing the first line of each statement.  If it
didn't, well life sucks.

In the same compiler, only the first four characters of keywords at the
beginning of lines were examined.  Thus, the following statement would
produce the following results:

INTEGR ABC, DEF

the variables BC and DEF were declared integers (INTE was checked, and the
next two characters were skipped).

This compiler was later extensively modified to become the first prime
fortran compiler, but most of the really braindamaged parts got patched up
at this point in time ...
-- 
				Rich Welty

	(I am both a part-time grad student at RPI and a full-time
	 employee of a local CAE firm, and opinions expressed herein
	 have nothing to do with anything at all)

	CSNet:   weltyrp@rpi
	ArpaNet: weltyrp.rpi@csnet-relay
	UUCP:  seismo!rpics!weltyrp