<div dir="ltr"><div dir="ltr">Thanks for the reply Jose,</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jul 8, 2026 at 3:12 AM Jose E. Marchesi <<a href="mailto:jemarch@gnu.org">jemarch@gnu.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Chris.<br>
<br>
> Good afternoon everyone,<br>
><br>
> I am trying to find clarity on "the proper way" of handling of line (and<br>
> page) endings in Algol 68 transput.<br>
><br>
> Back in the day, I wrote several articles on Algol 68 for<br>
> <a href="https://www.opensource.com" rel="noreferrer" target="_blank">https://www.opensource.com</a>. In one, I talked about using closures with<br>
> "here procedures" to facilitate processing data from delimited text files.<br>
><br>
> Doing that, I found that when I wanted to read a line of text I needed to<br>
> include "newline" in order to skip over line-ending characters; for example:<br>
><br>
> file inf;<br>
> open(inf, input_file_name, stand_in_channel);<br>
> bool finished_reading := false;<br>
> on logical file end (inf, (ref file f) bool: finished_reading := true);<br>
> while<br>
> string line;<br>
> get(inf,(line, newline));<br>
> not_finished_reading<br>
> do<br>
> ...<br>
> od<br>
><br>
> (this was using Algol 68 Genie at that time).<br>
><br>
> However, in McGettrick p.38, I read (for example):<br>
> --<br>
> The effect of a read statement such as<br>
> read((a, b, c, d)<br>
> is, at least for present purposes, the same as the four read statements<br>
> read(a); read(b); read(c); read(d)<br>
><br>
> It is convenient therefore to consider only read statements of the form<br>
> "read(a)" where "a" is a single variable or, more precisely, a single<br>
> object. The effect of more complex read statements can then be defined in<br>
> terms of the simpler statements.<br>
><br>
> The effect of "read(x)" will now be considered. There are several cases to<br>
> be discussed. These arise from the different possible modes of "x".<br>
> (i) Suppose "x" has mode "ref int". The input is devoured until the first<br>
> non-blank character is encountered. Newlines are taken if necessary. The<br>
> integer is then read and assigned to the variable "x". It will be<br>
> terminated by a non-digit character or by a new line, whichever comes<br>
> first...<br>
> ...<br>
> (iv) Suppose "x" has mode ref char. If the reading position is at the end<br>
> of the line, a new line is taken. The first character is read and assigned<br>
> to "x".<br>
> --<br>
><br>
> This "Newlines are taken if necessary" approach does not seem to match my<br>
> experience with reading a text file line by line into ref string<br>
> variables. Explicitly, as I mentioned above, to move to the next line in<br>
> order to read it, I had to issue a newline.<br>
><br>
> Does anyone have any advice on this matter?<br>
<br>
This is specified in the Report:<br>
<br>
<br>
10.3.3.2. Formatless input<br>
<br>
<br>
[...]<br>
<br>
ff) If the mode of N is specified by ref char, then first, if the<br>
current line is exhausted, a good position is found on a subsequent<br>
line; next, a character is read and assigned to N.<br>
<br>
gg) If the mode of N is specified by ref[]char, then input takes place<br>
(as in ff) to the subnames of N one after the other (with new lines<br>
being taken as required).<br>
<br>
hh) If the mode of N is specified by ref string, then characters are<br>
read until either<br>
<br>
(i) a character is encountered which is contained in the string<br>
associated with the file by a call of the routine make_term, or<br>
<br>
(ii) the current line is exhausted, whereupon the event routine<br>
corresponding to on_line_end (or, where appropriate, to on_page_end,<br>
on_physical_file_end or on_logical_file_end) is called; if the event<br>
routine moves the current position to a good position, then input of<br>
characters is resumed.<br><br></blockquote><div>This is great info, thanks a lot for that. I've reviewed §10.3.3.2 in the RR and I find the paragraph subsequent to hh-ii) to be also informative:</div><div><br></div><div>The string consisting of the characters read is assigned to N (note that, if<br>the current line has already been exhausted, or if the current position is at<br>the start of an empty line or outside the logical file, then an empty string<br>is assigned to N) .)</div><div><br></div><div>I also had another trawl through McGettrick and I see on p. 203 Example 7.1.5b Reading strings of characters:</div><div>--</div><div>string s, t; read((s,t))</div><div>results in t being assigned the empty string since reading into s leaves the current reading position at the end of a line or the logical end of file.</div><div>--</div><div><br></div><div></div><div>So generally speaking, when we're reading a string:</div><div><br></div><div>- we don't want "on_line_end" to move to the beginning of the next line or we will end up with the entire contents of the file from the starting position in the string with no separators between lines;</div><div>- therefore we want to use "newline" to advance over the line end if we intend to read each line of the file into a string.</div><div><br></div><div>I also see in RR p.163:</div><div><br></div><div>mode ?- in type = c an actual-declarer specifying a mode united from<br>(2.1.3.6.a} 'reference to flexible row of character' together with a<br>sufficient set of modes each of which is 'reference to' followed by<br>a mode which does not contain 'flexible', 'reference to',<br>'procedure' or 'union of' c;</div><div><br></div><div>I had not previously connected all the dots on "does not contain 'flexible'" - ie the only flexible row mode that "get" is prepared to handle is "string".</div><div><br></div>Looking more deeply into van Vliet's code for "get" I see that he does in fact handle ref [] char and string differently.</div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Chris Hermansen · clhermansen "at" gmail "dot" com<br><br>C'est ma façon de parler.</div></div></div>