Literals/String: Difference between revisions

Content deleted Content added
Dinosaur (talk | contribs)
→‎{{header|Fortran}}: Some spaces are emptier than others.
Line 551:
10 PRINT 1,ATWT(I)
END </lang>
Evidently, the syntax highlighter here does not recognise the Hollerith style usage. Nor do some compilers, even if in its original home within FORMAT statements.
 
The first PRINT statement writes out a heading, here with lower case letters as an anachronism. Then the loop reads a deck of cards containing the name of an element and its atomic weight into an array ATWT, but the special feature is that the first twelve characters of each card replace the text in the FORMAT statement, and thus the following PRINT statement shows the name of the element followed by its atomic weight as just read.
 
Fortran IV introduced a text literal, specified within apostrophes, with two apostrophes in a row indicating an apostrophe within the text. Later, either an apostrophe or a double quote could be used to start a text string (and the same one must be used to end it) so that if one or the other were desired within a text literal, the other could be used as its delimiters. If both were desired, then there would be no escape from doubling for one. Because spaces are significant within text literals, a long text literal continued on the next line would have the contents of column seven of the continuation line immediately following the contents of column 72 of the continued line. F90- formalisedexcept an opportunitythat (for free-formatsome sourcecompilers reading disc files;) manyif compilerssuch hadlines alsodid allowednot usageextend beyondto column 72 (because trailing spaces were trimmed from the records) rather less text would be defined. So, even though this is in fixed-format (or card image) style, again misinterpreted by the syntax highlighter, <lang Fortran> BLAH = "
1Stuff"</lang>
might be the equivalent of only <code>BLAH = "Stuff"</code> instead of defining a text literal with many leading spaces. F90 formalised an opportunity for free-format source files; many compilers had also allowed usage beyond column 72.
 
Within the text literal, any character whatever may be supplied as texttextEvidently, the syntax highlighter here does not recognise the Hollerith style usage. Nor do some compilers, even if in its original home within FORMAT statements. grist, according to the encodement recognised by the card reader as this was a fixed-format file - cards have an actual physical size. This applied also to source text held in disc files, as they were either fixed-size records or, for variable-length records, records had a length specification and the record content was not involved. Variable-length records were good for omitting the storage of the trailing spaces on each line, except that the sequence numbers were at the end of the line! In this case they might be omitted (unlike a card deck, a disc file's records are not going to be dropped) or there may be special provision for them to be at the start of each line, with the source text's column one staring in column nine of the record. But, for the likes of paper tape, the question "How long is a record?" has no natural answer, and record endings were marked by a special symbol. Such a symbol (or symbol sequence) could not appear within a record, such as within a text literal and be taken as a part of the text. This style has been followed by the ASCII world, with variously CR, CRLF, LFCR and CR sequences being used to mark end-of-record. Such characters cannot be placed within a text literal, but the CHAR(n) function makes them available in character expressions. Some compilers however corrupt the "literal" nature of text ''literals'' by allowing escape sequences to do so, usually in the style popularised by C, thus \n, and consequently, \\ should a single \ be desired.
 
Some examples, supposing that TEXT is a CHARACTER variable. <lang Fortran> TEXT = 'That''s right!' !Only apostrophes as delimiters. Doubling required.
Line 562 ⟶ 566:
TEXT = 'He said "That''s right!"' !Though one may dabble in inconsistency.
TEXT = 23HHe said "That's right!" !Some later compilers allowed Hollerith to escape from FORMAT. </lang>
Evidently, the syntax highlighter here does not recognise the Hollerith style usage. Nor do some compilers, even if in its original home within FORMAT statements.
 
A similar syntax enables the specification of hexadecimal, octal or binary sequences, as in <code>X = Z"01FE"</code> for hexadecimal (the "H" code already being used for "Hollerith" even if the H-usage is not supported by the compiler) but this is for numerical values, not text strings. While one could mess about with EQUIVALENCE statements, numbers fill up from the right while text strings fill from the left and there would be "endian" issues as well, so it is probably not worth the bother. Just use the CHAR function in an expression, as in