From: Dick Hendrickson <dick.hendrick...@att.net>
Subject: Re: How long can a statement be?
Date: 2000/03/08
Message-ID: <38C6BB9C.3713683E@att.net>#1/1
X-Deja-AN: 594857241
Content-Transfer-Encoding: 7bit
References: <Pine.SOL.3.96.1000306155954.2656A-100000@cplusplus.gaul.csd.uwo.ca> <uebt4rpwym.fsf@altair.dfrc.nasa.gov> <8a44ub$8vk$2@metro.ucc.usyd.edu.au> <8a6c85$6j3$2@bob.news.rcn.net>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 952548083 12.75.166.253 (Wed, 08 Mar 2000 20:41:23 GMT)
Organization: AT&T Worldnet
MIME-Version: 1.0
NNTP-Posting-Date: Wed, 08 Mar 2000 20:41:23 GMT
Newsgroups: comp.lang.fortran



Robert Orban wrote:
> 
[snip]
> 
> Dare I ask, in this day of editors with automatic word-wrap, automatic
> indentation, and automatic formatting, why there is _any_ limit to the
> length of a line?
> 

Partly, it's tradition.  

Other reasons include:  

It's hard to know how to format error messages when lines are really
long.  

If there is no limit in the standard, each vendor will (probably) impose 
a limit and codes won't really be portable.  Hard disk size (if nothing 
else) will stop most any line eventually.

Different screens/OSs/compilers will wrap lines at different points and
make portable reading of long code lines hard for humans.

The big one in my mind is internal representation and optimization.
Optimizing compilers look at each token a ton of times and it's nice
to have the internal representation be compact (ie "fit in a word").  
It's also nice to have things like open parens point to their matching 
close paren, have the beginning of one statement point to the start of 
either (or both) the previous or next statement, etc.
If the line length is unlimited, then there is no practical way to
set up reasonably small fields for these pointers.  Again, different
vendors are likely to impose different limits, based on token counts
rather than lines and characters, and portability will suffer.

None of these are obvious killers, but they add up to a "reason" to
specify a size in the standard; especially since very few codes
"really really" need real long lines.

Dick Hendrickson