How long can a statement be?
Sami SIDHOUM
I am using f90 to compile my fortran codes. It seems to me that if a
statement line is too long, it generates errors. Is this true? How can I
write a line of code on two lines?
To illustrate what I mean, here is a line that seems to sisplease f90:
PRINT *,'---------------------------------------------------
------------------------------------------------------------
---------------------------------------------------------------------'
(all on one line of course)
Thanks for your help.
Sami.
Dick Hendrickson
continued by using an & character at the end of the line and optionally
at the start of the next line. Character constants require the & at the
start of the next line (so the compiler knows whether or not leading
blanks are significant.)
So, you could do yours as:
PRINT *,'---------------------------------------------------&
&------------------------------------------------------------&
&---------------------------------------------------------------------'
As a matter of style I like to use concatination for continuing
characters. Something like:
PRINT *,'---------------------------------------------------'// &
'------------------------------------------------------------'// &
'---------------------------------------------------------------------'
because the rules for where the & must go and what to do about leading
blanks and trailing comments seem easier to me.
For your specific example, something like
print '(150a)', ('-', i = 1,100)
might be better. It's more compact, and it's obvious that you will
get 100 dasheson the output line.
Dick Hendrickson
Richard Maine
> I am using f90 to compile my fortran codes. It seems to me that if a
> statement line is too long, it generates errors. Is this true?
Yes. Though the question seems simple, the full answer is fairly
complicated because there are many cases. For a start, the answers
are quite different depending on whether you are using fixed source
form or free source form. I'll shorten my reply by giving answers
for only free source form, which is what most new f90 code gets
written in.
In free source form, a statement can be up to 40 lines long and each
line can have up to 132 characters.
line looks
> How can I write a line of code on two lines?
It depends on whether you are trying to split the line in the middle of
a character string. (Standard-speak is "in a character context").
If you are not in the middle of a character string, then just put an &
character at the end of each line except for the last. Example
write (*,*) a_variable, &
and_another, &
yet_another
Unfortunately, your sample *does* have a single long character string, so
its not quite that simple. I generally recommend changing the code so
that it has multiple character strings, each one one line. Then you can
use the above-described continuation mechanism. You can split the string
and then use string concatenation (the // operator) to concatenate the multiple
shorter strings, as in
write (*,*) 'here is---------------' // &
'a long string------------------' // &
'built by concatenating parts.'
I was going to suggest just using multiple unconcatenated strings as an
alternative, but it then occurred to me that this is likely to end up
putting them on separate lines if your list-directed output gets longer
than the system "likes". So I'll avoid getting into that complication.
If you *REALLY* want to have the whole thing as a single string without
using concatenation (something that I recommend against), then you have
to use the form of continuation that applies "in a character context",
as follows
Still put an & on the end of each line except the last. But in this
case, do not "close" the string that you started until the last line.
Put an & at the beginning of every line after the first. The
character string stops at the character right before the & on each
line, and it begins at the character right after the & on the
subsequent line. Note in particular that if you want to indent the
code, it is ok to indent befoire the & at the beginning of the lines,
but indentation after the leading & will end up as part of the string.
Example
write (*,*) 'this-long-string&
&has-no-blanks-in-it&
&anywhere.'
P.S. I haven't covered all of the style options. In particular, it is
allowed to have the leading & even in the non-character-context case,
but it doesn't do much "interesting" in that case, so I haven't
covered that. And fixed source form has a completely different set of
sizes, rules, and compiler-dependent quirks; with any luck you don't
have to deal with that.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
James Van Buskirk
Dick Hendrickson wrote in message <38C42E97...@att.net>...
>For your specific example, something like
> print '(150a)', ('-', i = 1,100)
>might be better. It's more compact, and it's obvious that you will
>get 100 dasheson the output line.
I also like to use
print *, repeat('-', 100)
to do this kind of task.
Emilio Lopes
> Dick Hendrickson wrote in message <38C42E97...@att.net>...
> > print '(150a)', ('-', i = 1,100)
> I also like to use
> print *, repeat('-', 100)
> to do this kind of task.
Or still
print '(100(''-''))'
nor...@mech.eng.usyd.edu.au
: In free source form, a statement can be up to 40 lines long and each
: line can have up to 132 characters.
As a matter of interest, does anyone know why the number 132 was chosen?
I can understand the origins of the fixed-source length of 72 characters
(punch cards being 80 characters long, less 8 for putting those line
numbers in the right hand columns), but why 132 for the new source form?
I would have imagined that computer scientist types would have pushed for
128 (and maybe Cray programmers 129) so why 132?
--
Stuart Norris nor...@mech.eng.usyd.edu.au
Mechanical Engineering,University of Sydney,NSW 2006 wk:+(61 2) 9351-2272
http://flo.mech.eng.usyd.edu.au/norris hm:+(61 2) 9326-5276
Richard Maine
> Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
> : In free source form, a statement can be up to 40 lines long and each
> : line can have up to 132 characters.
>
> As a matter of interest, does anyone know why the number 132 was chosen?
I don't actually know. A plausible guess might be that its the width
of some common terminals. Its also about the max width of the typical
old line-printer, but I can't figure out why anyone would care about that
for the purpose, so that's probably a coincidence.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
James Giles
nor...@mech.eng.usyd.edu.au wrote in message <8a44ub$8vk$2...@metro.ucc.usyd.edu.au>...
>Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
>: In free source form, a statement can be up to 40 lines long and each
>: line can have up to 132 characters.
>
>As a matter of interest, does anyone know why the number 132 was chosen?
>(punch cards being 80 characters long, less 8 for putting those line
>numbers in the right hand columns), but why 132 for the new source form?
>I would have imagined that computer scientist types would have pushed for
>128 (and maybe Cray programmers 129) so why 132?
40 times 132 is 5280. They wanted to allow statements a mile long?
--
J. Giles
Gordon Sande
>Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
>: In free source form, a statement can be up to 40 lines long and each
>: line can have up to 132 characters.
>
>As a matter of interest, does anyone know why the number 132 was chosen?
>I can understand the origins of the fixed-source length of 72 characters
>(punch cards being 80 characters long, less 8 for putting those line
>numbers in the right hand columns), but why 132 for the new source form?
>I would have imagined that computer scientist types would have pushed for
>128 (and maybe Cray programmers 129) so why 132?
Standard line width of printers.
133 if you count the carriage control and some printers had a manual
override so you could see your erroneous carriage control.
Jokes about multiple trees are all too true.
You aint seen nothing until you have seen a fast printer skipping form
due to an error in carriage control. Good printers even had a fast
skip mode for forms that had only a little bit of printing on them.
Before you make too much fun of such printers take a look at a typical
paycheck.
Michel OLAGNON
>Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
>: In free source form, a statement can be up to 40 lines long and each
>: line can have up to 132 characters.
>
>As a matter of interest, does anyone know why the number 132 was chosen?
>I can understand the origins of the fixed-source length of 72 characters
>(punch cards being 80 characters long, less 8 for putting those line
>numbers in the right hand columns), but why 132 for the new source form?
>I would have imagined that computer scientist types would have pushed for
>128 (and maybe Cray programmers 129) so why 132?
>
I am surprised that none of you imperial units users seem to remember that
listing paper was(is ?) 11 inches wide, with 12 characters per inch.
Michel
--
| Michel OLAGNON email : Michel....@ifremer.fr|
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|
| Centre de Brest - B.P. 70 phone : +33-2-9822 4144|
| F-29280 PLOUZANE - FRANCE fax : +33-2-9822 4650|
| http://www.ifremer.fr/ditigo/molagnon/molagnon.html |
James Giles
>listing paper was(is ?) 11 inches wide, with 12 characters per inch.
Yes, but listings are for annotated source, not raw reprints. Why would
the width of the source itself be that wide?
--
J. Giles
Michel OLAGNON
Well, it is a committee's decision, but I find it rather logical. I have
worked for years with lines 132c wide, that were the output, and the input,
as soon as we had disc or tape files, of our FORTRAN programs. Only
source code had to remain within the 80c limit because it had to fit on cards.
132 was a kind of standard length for formatted records.
If you still want to read sometimes your programs, but find 80c too few, 132
is thus the next natural step (and Fermat's last theorem is solved, so we don't
need wide margins for annotations any more ;-)).
Michel
N. Shamsundar
11 X 14
(inches) and 132 in base 11 is 110?
N. Shamsundar
University of Houston
nor...@mech.eng.usyd.edu.au wrote:
>
> Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
> : In free source form, a statement can be up to 40 lines long and each
> : line can have up to 132 characters.
>
> As a matter of interest, does anyone know why the number 132 was chosen?
> I can understand the origins of the fixed-source length of 72 characters
> (punch cards being 80 characters long, less 8 for putting those line
> numbers in the right hand columns), but why 132 for the new source form?
> I would have imagined that computer scientist types would have pushed for
> 128 (and maybe Cray programmers 129) so why 132?
>
Dick Hendrickson
twice as long as the old and twice as wide (if you don't count the
first 5 columns of the first line of the old form.)
Other guesses are equally valid.
Dick Hendrickson
N. Shamsundar
centimiles?
N. Shamsundar
University of Houston
James Giles wrote:
>
> nor...@mech.eng.usyd.edu.au wrote in message <8a44ub$8vk$2...@metro.ucc.usyd.edu.au>...
> >Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
> >
> >: In free source form, a statement can be up to 40 lines long and each
> >: line can have up to 132 characters.
> >
> >As a matter of interest, does anyone know why the number 132 was chosen?
> >I can understand the origins of the fixed-source length of 72 characters
> >(punch cards being 80 characters long, less 8 for putting those line
> >numbers in the right hand columns), but why 132 for the new source form?
> >I would have imagined that computer scientist types would have pushed for
> >128 (and maybe Cray programmers 129) so why 132?
>
James Giles
>James Giles wrote:
>>
>> 40 times 132 is 5280. They wanted to allow statements a mile long?
N. Shamsundar wrote in message <38C6990F...@uh.edu>...
>Oh my! They had characters a foot long? Or are we talking
>centimiles?
You use the font you want, I'll use the font I want.
--
J. Giles
Robert Orban
>
>Richard Maine <ma...@altair.dfrc.nasa.gov> expounded:
>
>: In free source form, a statement can be up to 40 lines long and each
>: line can have up to 132 characters.
>
>As a matter of interest, does anyone know why the number 132 was chosen?
>I can understand the origins of the fixed-source length of 72 characters
>(punch cards being 80 characters long, less 8 for putting those line
>numbers in the right hand columns), but why 132 for the new source form?
>I would have imagined that computer scientist types would have pushed for
>128 (and maybe Cray programmers 129) so why 132?
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?
In another thread, the point was made that the main purpose of a high-level
language was to remove bookkeeping burdens from the programmers. Why on
earth, in the year 2000, should anyone have to count the number of
characters in each line? Didn't that go out with EDLIN?
tho...@antispam.ham
> One possibility is that 132 is 2 * 66, so the new source form is
> twice as long as the old and twice as wide (if you don't count the
> first 5 columns of the first line of the old form.)
I thought that the original computer display monitors were designed
to handle 80 columns because that's how many columns were on punch
cards. Later, when someone came out with a monitor to handle more
colums (was DEC the first?), possibly in response to a customer
request, they made it 132 columns, so perhaps Fortran 90 simply
adopted this number for the new upper limit on line length. Of
course, it still doesn't explain why 132 was originally chosen, but
I haven't seen anyone ask why 80 was chosen for the number of columns
on the original punch cards either. The best explanation I've seen
for the choice of 132 has to do with the number of columns on a
15 by 11 inch line printer.
Dick Hendrickson
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
Michel OLAGNON
>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?
>
You have to understand that the limit is a lower limit, not an upper one.
Any standard compiler MUST accept lines 132c long. There will obviously
be some upper limit, since I cannot imagine the standard stating:
Whatever arbitrary large number N, the system shall accept input lines
of at least N+1 characters. It would then be easy to sue vendors ;-)
The present standard garanties that this limit is not going to be less
than 132c with any vendor, and as a user, this is what I want.
Richard Maine
> In article <38C6BB9C...@att.net>, dick.hen...@att.net says...
> >If there is no limit in the standard, each vendor will (probably) impose
> >a limit and codes won't really be portable....
> >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.
>
> OTOH, the downside of a 132-character limit...
> I have often encountered situations in my work where I work with _very_
> long expressions...
This seems to miss the main point Dick (and some others) was making. If
the standard did not specify a limit, that would *NOT* guarantee that
your long lines would work. It would just mean that you would have no
idea whether or not to expect *ANY* length to work. Some compilers might
accept only the 72 columns of the old source form. Wouldn't surprise me
if 80 wasn't the limit of others. And perhaps some would accept 255,
or maybe 32767, or .... A compiler would be perfectly standard conforming
(if a bit unpopular) if it accepted only 40 columns.
It is quite common for users to misinterpret the standard in this kind of
way - thinking that if only the standard didn't specify a limit, then this
would automatically mean that there were no limits. Sometimes the presense
of a limit can be liberating - it means that as long as you stay within
the limit, then you are freed from having to worry about whether or not
the compiler will accept that much.
Now if you want to argue that 132 is too small a number...that's (in
my opinion) more worthwhile to argue. If you want to argue that there
should be no specified limit because longer lines are useful, then one
of us doesn't understand (if its not you, then maybe its me).
Actually, I'd probably argue against limits much longer than the 132
anyway. Nothing comes for free, including this. Even though there
might be a few cases where it was useful, I suspect the costs would be
larger than the benefit. Yes, these things can cost. For example,
there's the major vendor (I'll avoid names because the data might have
been intended to be given me in confidence - it wasn't explicit) that
would have to do major redesign of the compiler if total allowed
statement length (including continuation lines) went over 16k. I'll
not argue about whether or not this reflects desirable design (I'm
not even sure that the vendor employee who mentioned it necessarily
thought it good). But I certainly can recognize it as a cost issue,
measurable in hard dollars in that case.
--
Richard Maine
ma...@qnet.com
Robert Orban
>>
>[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?
>>
>
>
>Other reasons include:
>
>It's hard to know how to format error messages when lines are really
>long.
>
>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.
>
>specify a size in the standard; especially since very few codes
>"really really" need real long lines.
OTOH, the downside of a 132-character limit is not only the need to keep
track of the length of the line, but to remember how to do with special
cases, like the "continuation in the middle of a string" case.
I have often encountered situations in my work where I work with _very_
long expressions (often machine-generated by computer algebra programs). I
remember one (a passive LC filter transfer function) that went to 19
continuations of fixed-format 72-character lines. With essentially
unlimited line length (say 5000 characters), it is very easy to format
these for Fortran. But if your computer algebra program has automatically
cut up the lines to accomodate fixed line lengths, it becomes, with the
current standard, quite inconvenient to (1) make corrections that are
longer than the incorrect code they replace (suddenly your corrected line
can exceed 132 characters), and (2) search-and-replace variable names if
you want new names that are longer than the old ones (same problem).
For some years I used Microway's NDP Fortran 77. Although it had a number
of other problems, it _did_ allow lines of up to 999 characters and tab
indenting, both of which I thought were extremely useful extensions.
Jan Vorbrueggen
> Yes, these things can cost. For example, there's the major vendor [...]
> that would have to do major redesign of the compiler if total allowed
> statement length (including continuation lines) went over 16k.
Anecdote: Some years past, the (then) VAX Fortran compiler had a bullet point
in its (as usual excellent) release notes that the limit of 65535 symbols
within one program unit had been lifted. I have always wondered who managed
to include so many COMMON blocks and PARAMETER statements to exceed that
(semi-arbitrary) limit.
Jan
Robert Orban
>
>robe...@orbanxyxy.com (Robert Orban) writes:
>
>> In article <38C6BB9C...@att.net>, dick.hen...@att.net says...
>
>> >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.
>>
>> I have often encountered situations in my work where I work with _very_
>
>This seems to miss the main point Dick (and some others) was making. If
>the standard did not specify a limit, that would *NOT* guarantee that
>your long lines would work. It would just mean that you would have no
>idea whether or not to expect *ANY* length to work. Some compilers might
>accept only the 72 columns of the old source form. Wouldn't surprise me
>if 80 wasn't the limit of others. And perhaps some would accept 255,
>or maybe 32767, or .... A compiler would be perfectly standard conforming
>(if a bit unpopular) if it accepted only 40 columns.
>
>It is quite common for users to misinterpret the standard in this kind of
>way - thinking that if only the standard didn't specify a limit, then this
>would automatically mean that there were no limits. Sometimes the presense
>of a limit can be liberating - it means that as long as you stay within
>the limit, then you are freed from having to worry about whether or not
>the compiler will accept that much.
>
>Now if you want to argue that 132 is too small a number...that's (in
>my opinion) more worthwhile to argue. If you want to argue that there
>should be no specified limit because longer lines are useful, then one
>of us doesn't understand (if its not you, then maybe its me).
As an engineer, I can't argue for unlimited line lengths for obvious reasons.
I had casually proposed a 5000 character limit in my earlier post, mainly
because I have never, in my own work, come across a requirement nearly that
long. (In fact, the original fixed form standard, if memory serves, specifies
up to 19 continuation lines, or a total of 1440 characters in a statement.)
IMHO, a 5000 character limit would comfortably accommodate virtually any
requirement. We would then let the editor worry about indents, line breaks,
and "prettyprinting." We could easily correct, and search and replace within
a line without worrying that the length limit's being exceeded. After any
such change, the editor would immediately and automatically reformat the line
on the display device. (I am describing little more than what every word
processor, from "Electric Pencil" on down, already does. It's hardly rocket
science!)