CSV to HTML translation: Difference between revisions
→{{header|Fortran}}
(→{{header|Fortran}}: Explicate.) |
|||
Line 1,466:
The key statement is the compound WRITE statement and its associated FORMAT, and for non-furrytranners these proceedings may be obscure. A WRITE statement accepts a list of items to be written in the usual manner, and an item is usually the name of a variable or an expression (such as 2*X + 1), but it can also be an implied DO-list. In this case the item is enclosed in brackets, and within them starts with an item list followed by a comma and a DO-expression, as in <code>(a,b,c, I = 1,N)</code> where ''a'', ''b'' and ''c'' constitute a three-element list of items - any of which could themselves be an implied DO-list if nested lists were desired. Thus, by one means or another, the WRITE statement produces a sequence of values (of various types) to be sent forth. In association with the list of entries in the nominated FORMAT statement: processing proceeds in parallel through both lists in the manner of coroutines, not sequentially. It is possible with a READ statement that a value just read adjusts a part of a FORMAT statement not yet encountered during the processing of the READ statement. For instance FORMAT 13 could have <NCOLS> instead of 666 as its repeat count, but this is an extension to F77 and avoided here to stick with older abilities except where inconvenient.
Thus, the entire line for a table row can be written in one go, starting with the tr then many repetitions of (WOT,''text'', WOT), with each starting and ending WOT appropriately encased by < and > and / characters supplied by the FORMAT. This repeated pattern is unsuitable for starting the line (so the tr is provided by the FORMAT, with indentation) because then it would be out of step, but happily, after the last text is rolled, the required /tr can be sent to use the format codes that would normally be used for the start of the next text. Humm. If there ''were'' to be 666 texts to roll, this will exhaust the FORMAT statement and it will start a new line and roll forth a tr again. So, just in case, the repeat count should be 667 (or <NCOLS + 1>),
The check for a comma is not <code>ALINE(I:I).EQ.","</code> because in other work this usage has been found to evoke astoundingly bad code, notably that ''both'' appearances of "I" are checked as being within bounds, and, the length is calculated by subtracting the "first" (I) from the "last" (also I) at run time! At least by the COMPAQ F90/95 compiler. By contrast, the ICHAR usage, which can only be for a single character, lacks this madness and far superior speed results. Not important in this example, but it explains why this usage appeared in a prog. at the Culham Science Centre in source from an IBM mainframe.
| |||