{"id":11114,"date":"2025-07-14T01:02:00","date_gmt":"2025-07-14T05:02:00","guid":{"rendered":"https:\/\/www.both.org\/?p=11114"},"modified":"2025-07-14T06:55:53","modified_gmt":"2025-07-14T10:55:53","slug":"a-small-algol-68-project-part-2","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=11114","title":{"rendered":"A Small Algol 68 Project, Part 2"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

In memory of J. Kevin Douglas, a good friend and fellow fan of Algol 68<\/em><\/p>\n\n\n\n

In the last article in this series<\/a>, we described a simple linear least squares problem – fitting a line to a sequence of (x,y) coordinates – and we wrote a small Algol 68 program to create a test data set for use in the development of a program to carry out this fitting operation.<\/p>\n\n\n\n

In this article, we will develop a small collection of useful routines for reading text files and extracting data from them, setting us up for a more streamlined solution to the least squares problem.<\/p>\n\n\n\n

Files in Algol 68<\/strong><\/h2>\n\n\n\n

I would venture to guess that most of us think of files, especially text files, as collections of characters with intervening line breaks.  But back in the days when Algol 68 was being designed and dinosaurs<\/s> mainframes ruled the world, there was a tendency to think of files in terms of things like record length and access methods.  In the IBM mainframe world, access methods referred to whether files were suitable for sequential or random record access, whether they could be lengthened or shortened and so on.  Many applications, including compilers for programming languages like FORTRAN, COBOL or PL\/1 were originally designed to interpret input coming from 80 column keypunch cards<\/a>.<\/p>\n\n\n\n

Moreover, different mainframes had differing word lengths; for example, the Univac 1100 series <\/a>used a 36 bit word, whereas the IBM 360 and successors used a 32 bit word.  Those 36 bit words in the Univac mainframes held six 6-bit characters<\/a>, encoded according to the US Army FIELDATA communications standard (upper case letters, numbers and a few symbols).  The IBM 360\u2019s 32 bit words held four 8-bit characters<\/a> encoded as EBCDIC.<\/p>\n\n\n\n

Contrast this to our current perspective of 32 and 64 bit words and Unicode character encoding<\/a>.<\/p>\n\n\n\n

Given that Algol 68 was designed according to the file gestalt of the 1960s, I find it kind of surprising that it seems to work quite well with the \u201cfile as stream of characters\u201d mindset that really kind of took flight thanks to the approach to files taken by the early Unix developers.<\/p>\n\n\n\n

So let\u2019s dig in.<\/p>\n\n\n\n

Like many modern programming languages, Algol 68 relies on opening files in order to acquire the ability to read or write them and closing them in order to relinquish this ability.<\/p>\n\n\n\n

The act of opening a file is handled by the open procedure defined as:<\/p>\n\n\n\n

PROC open = (REF FILE f, STRING idf, CHANNEL chan) INT<\/code><\/code><\/pre>\n\n\n\n
The first parameter is a reference to an Algol 68 file data structure – the FILE<\/code> – which is set by the procedure and returned to the caller.<\/p>\n\n\n\n
The second parameter is the constant externally-known name of the file; its identifier, STRING idf<\/code>.<\/p>\n\n\n\n
The third parameter is the channel – CHANNEL<\/code> – to be used for reading from or writing to the file.  Back in the 60s, channels were the means to associate the program endpoint (the FILE<\/code>) with the external storage referred to by the file name.<\/p>\n\n\n\n
A call to OPEN()<\/code> returns an integer value which is the return code – the result – of attempting to open the file.<\/p>\n\n\n\n
Algol 68 Genie pre-defines a standard set of FILE<\/code>s (stand in, stand out, stand error <\/code>and stand back<\/code>) and a standard set of CHANNEL<\/code>s (stand in channel, stand out channel, stand error channel, stand back channel, stand draw channel<\/code>).1<\/a><\/sup>  As in most programming languages used in Linux, we can associate those with physical files on the terminal command line.<\/p>\n\n\n\n
We can also define our own FILE<\/code> and associate it with one of the existing channels (the purpose of the open()<\/code> procedure).  And of course there are other operations we can undertake; but for the purposes of this article, we\u2019re really only interested in reading the file, detecting the end of file while reading and closing it once we\u2019re done.<\/p>\n\n\n\n
The get()<\/code> procedure is typically used to read lines from a file:<\/p>\n\n\n\n
PROC get = (REF FILE f, [] UNION (INTYPE, PROC (REF FILE) VOID) items) VOID<\/code><\/code><\/pre>\n\n\n\n
We see that get()<\/code> is passed a reference to the FILE<\/code>, allowing it to update the FILE<\/code> object; and a complicated looking thing – an array of united modes, which can be either mode INTYPE<\/code> or a PROC<\/code>.  I don\u2019t really want to make a huge digression at this point into united modes in general nor to INTYPE<\/code>, which is itself a kind of united mode.  Those impatient to find out more may wish to consult Chapter 7 of the Algol 68 Genie learning guide.2<\/a><\/sup>  Suffice to say for now that get()<\/code> can be made to return all manner of things if they are properly formatted; we will use it to return lines of the file, one by one. <\/p>\n\n\n\n
The on logical file end()<\/code> procedure is used to register a procedure to be called when reading reaches the end of the file:<\/p>\n\n\n\n
PROC on logical file end = (REF FILE f, PROC (REF FILE) BOOL p) VOID<\/code><\/code><\/pre>\n\n\n\n
This procedure is an interesting thing – it detects an event<\/em> – in this case, reaching the logical end of the file – and calls another procedure to deal with that situation – what we might call a listener<\/em> in today\u2019s jargon.<\/p>\n\n\n\n
The close()<\/code> procedure is used to cleanly sever the connection between the external file and the program:<\/p>\n\n\n\n
PROC close = (REF FILE f) VOID<\/code><\/code><\/pre>\n\n\n\n
We can see that there is some boiler plate code involved here that we might not wish to deal with every time we want to read a text file, so let\u2019s encapsulate this code in our own procedure to simplify its use.<\/p>\n\n\n\n
Streamlined text file reading in Algol 68<\/strong><\/h2>\n\n\n\n
Here is a procedure to streamline reading a text file line by line:<\/p>\n\n\n\n
1 PROC each line = (STRING input file name, PROC (STRING, INT) VOID l) VOID:\n2 BEGIN\n3     FILE input file;\n4     VOID(open(input file, input file name, standinchannel));\n5     BOOL fr := FALSE;\n6     on logical file end (input file, (REF FILE f) BOOL: fr := TRUE);\n7     INT linecount := 0;\n8     WHILE\n9         STRING line;\n10         get(input file,(line, newline));\n11         NOT fr\n12     DO\n13         linecount +:= 1;\n14         l(line, linecount)\n15     OD;\n16     close(input file)\n17 END # each line #;<\/code><\/pre>\n\n\n\n
Let\u2019s walk through this line by line:<\/p>\n\n\n\n
Line 1 declares the procedure, which takes a STRING<\/code> argument (the external file name) and a PROC<\/code> to be called to process each line once it\u2019s read, returning VOID<\/code> (no value).  Here you see Algol 68 giving us the ability to use what are called \u201chere procedures\u201d or \u201clambdas\u201d or \u201cclosures\u201d (with apologies for trampling on some fine distinctions here).  We\u2019ll see how this is used below in a simple example.<\/p>\n\n\n\n
Line 2 declares the variable input file<\/code>.<\/p>\n\n\n\n
Line 3 opens the input file<\/code>  using the input file name<\/code> parameter and associates that with standin channel<\/code>.  The call is wrapped in a coercion of the return value to VOID<\/code>. We\u2019ll assume for now that the user is careful to check that the external file exists and is readable, and doesn’t bother checking a return code.  Is this good design?  Well maybe not really; but I’m not an immediate fan of bubbling up the return code from open()<\/code> to the caller of each line()<\/code>, either.  I guess we could just halt at this point…<\/p>\n\n\n\n
Lines 4 and 5 declare a variable fr<\/code> that is used to indicate whether or not the reading has reached the end of file; set fr<\/code> to FALSE<\/code> initially; and pass a listener procedure to on logical file end<\/code> that sets fr<\/code>  to TRUE<\/code> when the end of file is reached.<\/p>\n\n\n\n
Line 6 declares and initializes the line count<\/code> variable, to be passed to the line listener routine.<\/p>\n\n\n\n
Lines 8 through 12 merit careful attention, as they offer a minor but clear demonstration of the concept of a serial clause yielding a value.<\/p>\n\n\n\n