As Algol-60 had no reserved words, the language keywords had to be specially marked, e.g. prefixed with an underscore with a trailing space or semicolon (_begin _integer i;i:=42_end), or enclosed in quotes ('begin''real'pi;pi:=3.14'end'), or made distinct from regular identifiers in some other way. Note that in both cases all unnecessary spaces are deliberately omitted in those two examples.

I have two Algol-60 compilers working. One uses quotes for keywords and considers them as atomic tokens.

The other, dated 1st of May 1979, uses the underscore as a "mode switch" character up to the next non-alphabetical symbol, so one underscore at the beginning of a keyword is enough, but extra underscores don't hurt:

   1.   _BE__GIN_ _I_N_T_EGER_ I;
   2.  I:=42; OUTPUT(‘Z’, I) _EN_D



That being said, it follows that writing _BEGIN_INTEGER will not fly: an error "В ЯЗЫКЕ НЕТ СЛОВА BEGININTEGER", translated as "THERE IS NO WORD BEGININTEGER IN THE LANGUAGE" will follow.

Note that an underscore before a space character does not hurt either. However, any space in the middle of a keyword will result in the pieces considered as separate keywords:

   1.   _BE _GIN _END

     СТРОКА 1

     СТРОКА 1


Now, to the point. I had a vague recollection that Algol-60 allowed two ways to write the GOTO operator. Indeed, according to Algol 60 syntax versions, the Revised Report (1963) prescribes goto, whereas the Modified Report (1976) prescribes go to.

The compiler which uses quotes, dated 25th of January 1979, only allows 'GOTO'. Nothing to see there, moving along.

The other behaves as follows:

_BEGIN _GOTO L; L:_END naturally, works, as does

   1.   _BEGIN ____G_O_____T_O____ L; L:_END

as well as various other combinations of extra underscores; but

   1.   _BEGIN _GO
   2.  _TO L; L:_END

works just as well, to satisfy both variants of the syntax.

For a final experiment, what would an error message be for _BEGIN _GO _FOR L; L:_END? Somewhat unexpectedly, the compiler produces В ЯЗЫКЕ НЕТ СЛОВА GO ("there is no word GO in the language").


If there is absolutely no semantic difference between the two spellings of the GOTO operator, why bother implementing both? Or, to start with, why bother introducing ambiguity in the standard, forcing the compiler writers to waste valuable machine words to support somebody's pet peeve? (Those two were rhetorical, do not attempt to flag the question "opinion-based".)

I'm hoping there is a captivating story of heated discussions related to the space in "goto"/"go to" somewhere in the memoirs of the authors of the language, or their interviews. Is there?

  • 2
    As an aside, why did you mix Cyrillic and Latin letters in your transcript? Did you just pick the Cyrillic characters manually from a character map, or is this a reflection of how the characters are actually encoded on that system? Commented May 8, 2021 at 6:22
  • 1
    @user3840170 There were two commonly used encodings: one, GOST 10859, had Cyrillics plus DFGIJLNQRSUVWZ. In the emulator, I have to make a decision how to map ABCEHKMOPTXY - to Latin or Cyrillic. I've decided to favor Latin, so that the listings would be fully Latin if only Latin letters were used, and easily copy-pasted. This makes Russian error messages appear mixed-script, but that's much less of an inconvenience. The other encoding was ASCII/ISO based, but it was internal; the printers operated in the GOST encoding.
    – Leo B.
    Commented May 8, 2021 at 8:00
  • Hmm, if you can’t capture the output before it’s converted, you might mitigate this by buffering words and treating unambiguous-script characters as mode switches for ambiguous ones in the current word. This will fail for wholly-ambiguous words (HET / НЕТ), but then, so will anything else. Commented May 8, 2021 at 9:34
  • 2
    On Flexowriters, underscore did not move the carriage, so _b_e_g_i_n was how you typed begin, and FWIW, that was a single 8-bit symbol in the KDF9 filestore.
    – dave
    Commented May 8, 2021 at 13:04
  • 1
    I never understood the logic of using stropping at all. It seems like a deliberate policy of divorcing "the standard" from any real-world "implementation". But then the original standard also ignored other real-world requirements like I/O,. so maybe it was intended mainly as an academic exercise in language design. Other languages (e.g. PL/I, and all versions of Fortran up to the present) have no reserved words and don't require it.
    – alephzero
    Commented May 8, 2021 at 13:23

3 Answers 3


Here's a different take on the issue (thus a separate answer).

There is no such distinction.

I ran this program through the KDF9 Whetstone Algol translator:

_b_e_g_i_n_i_n_t_e_g_e_rn; n:=1;

It compiles just fine(though of course there's always the possibility of artifacts from the modern ASCII translation). My interpretation is as follows:

Spaces have no significance per language fiat, though their appearance within basic symbols is not explicitly mentioned. Because there is a small and finite set of delimiters in Algol60, a recognizer can trivially know that begininteger is the two tokens begin and integer (here I use boldface since I don't know how to underline in this markup).

That being the case, _g_o_t_o (or goto) is not distinguishable from _g_o _t_o (or go to).

You can regard underlining as a single-character shift prefix. With that interpretation, the lexer knows when it has recognized a basic symbol by its content, not by a terminating mark.

This does not readily transfer to stropping regimes that use enclosing characters (like 'go to' or "go to"), and indeed the same compiler refuses 'begininteger'n (diagnostic: no begin). I suppose the obvious implementation here is to isolate the word by closing delimiter and then decide if it's a valid symbol.


I took a look at Randell & Russell's Algol 60 Implementation, which is the book on the Whetstone Algol implementation. They describe a sort of lexical-analysis buffer that's 12 symbols long (where a symbol seems to include an underline flag that has been added, and spaces have already been discarded). When an underlined character appears at the output end for compilation, an attempt is made to match a known basic symbol in the remainder of the buffer - i.e., as I suspected, we're checking against known symbols, not expecting any detectable separator character.

(If that sounds weird to modern readers, don't forget that we're compiling from paper tape, and since I/O time dominates, the goal is to be able to compile in between characters being read. So the compiler is running a few characters behind the input routine).

And significantly for this question:

Naturally, spaces, changes to a new line, spurious case definition characters(*), etc., are allowed between the underlined characters of any basic symbol.

(*) footnote from me: Flexowriter paper tape code included 'case normal' and 'case shift' characters. It was essentially a 6-bit code.

With respect to notations like 'begin', I'm now not sure whether they were even allowed in this particular compiler. They might be part of the online front-end, since underlining without a dead underline key is horrible. I'll poke around some more when I get a moment.


I'm now running Whetstone papertape Algol locally under ee9.

The sequence _g _o _t _o (boldface equivalent g o t o) is perfectly acceptable, demonstrating for sure that spaces are insignificant.

Apostrophe stropping -- thus 'goto' -- is not accepted by the compiler.

Kidsgrove Algol does accept apostrophe stropping, but will only take 'goto', not 'go to' or 'go' 'to'.

tl;dr results mixed.

  • I see. Then the author of the compiler I was using was too strict for his own good.
    – Leo B.
    Commented May 8, 2021 at 16:52
  • To be fair, though we latterly regard the Revised Report as a masterpiece of concision compared to the turgidity of modern specifications (hello, Java!), it did leave quite a lot unsaid.
    – dave
    Commented May 8, 2021 at 16:54
  • FWIW, the other compiler I have allows ` ’BE GIN’ ’G OTO’ L; L:’END’`, so it means that what I've observed is an example of obsession with details by one compiler author.
    – Leo B.
    Commented May 8, 2021 at 17:31
  • 1
    Revised Report, Section 2.3: Typographical features such as blank space or change to a new line have no significance in the reference language. They, however, be used freely for facilitating reading.
    – texdr.aft
    Commented May 8, 2021 at 23:25
  • are you using ee9 or some other way to run algol?
    – davidbak
    Commented May 8, 2021 at 23:29

One may call it an issue of taste or linguistics. The point is that there isn't a English word 'goto'. These are two words. In fact, 'goto' would be pronounced different from 'go to'.

Hold your breath and take a step back. Try to view it and shed 40+ years of FORTRAN and BASIC indoctrination. Try to pronounce it like someone uninitiated with programming. It sounds awful, doesn't it? Way off the meaning. It almost hurts. ALGOL was, in its abbreviated way, meant to be readable by humans (*1).

The way later Sinclair ZX80 (4 KiB) BASIC is a great example of the same issue. The machine was meant to appeal to non professional users. The key words GOTO and GOSUB were spelled out as GO TO and GO SUB (*2).

Of course this was easy due the special way the Sinclairs used to enter keywords. When building a character input-based compiler, it gets a lot more effort to detect two 'words' as part of a single keyword. So obviously writing GOTO helps a lot ... except it sucks when reading.

This was a real war in the 1960s. Pick your side.

*1 - Heck, isn't that one of the reasons HLLs were developed in the first place?

*2 - It got changed with the ZX81, to be more in line with 'regular' machines. Pressure of the 'experts' I guess.

  • 3
    At that time Fortran ignored all blanks in the source code (even in the middle of variable names!) except in character strings, so you could write GOTO, GO TO, or even GOT O or G OTO if you preferred. (This was the cause of the apocryphal bug that "DO 10 K = 1.12" was a valid assignment statement (i.e. "DO10K = 1.12" not a typo for "DO 10 K = 1, 12") with a comma not a period.
    – alephzero
    Commented May 8, 2021 at 11:52
  • 2
    I:m not sure the argument about pronunciation is relevant. IMO the keyword "GOTO" is pronounced exactly the same as "GO TO". FWIW in modern Fortran, where blanks are significant, several keywords are permitted in either form (e.g. "end do", "end if", "in out" or "enddo", "endif", "inout") and the most bizarre one is "elsewhere" as a synonym for "else where" in a "where ... else where ... end where" construct. (And the fact that ALGOL source code is punctuated by "random" quote marks, underscores, etc, makes in unreadable by humans IMHO)
    – alephzero
    Commented May 8, 2021 at 13:34
  • 2
    @alephzero - As remarked elsewhere, an underscore is supposed to underscore some other character, not be displayed by itself. That there exists defective equipment is unfortunate but you can't blame that on the underscore! And of course I claim direct knowledge that the result was not unreadable, though I cannot here prove I am human.
    – dave
    Commented May 8, 2021 at 14:15
  • 1
    Re ZX81: it has been changed back to GO TO and GO SUB in ZX Spectrum, for whatever reason... Commented May 8, 2021 at 14:52
  • 1
    @alephzero: If one could have asked some people in 1950 to read aloud a document with the word "goto", I suspect many would have pronounced it as rhyming with the word "photo", the prefixes "moto-" or "roto-", or the names DeSoto or Toto. If it hadn't been originally written as "go to", it might still be pronounced that way, much like the Linux command that combines "su" [set user] and "do" [the English verb] is often pronounced "pseudo".
    – supercat
    Commented May 10, 2021 at 15:15

(Opinion - I doubt there is any answer that is not opinion, unless one of the parties involved shows up here).

I think it is just personal taste.

Algol Bulletin 38 contains a letter (page 8) signed by the future authors of the Modified Report, and there the separate go to is used.

Section 4.3, page 18, bears the heading Go to statements.

This apparently passed unremarked in the bulletin. so perhaps it was not regarded as controversial.

Contrariwise, AB39.3.2, page 32 contains a letter from Wichmann, one of the authors of the letter cited previously, which writes goto.

So it's difficult to conclude that there was any particular intent one way or the other.

  • Hmm... It looks like the "syntax versions" page I referred to is not right. The Revised report already has the space. So it it likely that the language always officially prescribed a space and had no alternatives, but the implementers either deviated from the standard or provided an alternative spelling for convenience.
    – Leo B.
    Commented May 8, 2021 at 16:03
  • 2
    I just now checked as well; I concur the Revised Report used go to, though it's possible there were multiple settings in type (these being the days of hot metal). For the record, the original Report also used go to. 'Hardware representation' was always allowed to do whatever it pleased, as long as the mapping to the reference language was specified.
    – dave
    Commented May 8, 2021 at 16:18
  • And just for completeness, the preliminary report on the IAL was also in the go to camp.
    – dave
    Commented May 8, 2021 at 16:25
  • Thank you this. I started to trawl through Algol Bulletin looking for such quotes, but you beat me to it. I was also going to point out that between Algol 60 revised and modified, Algol 68 was specified by IFIP WG 2.1 and would have had influence here etc. Commented May 9, 2021 at 12:55
  • 1
    Algol 68 has different problems, since there's now an infinite set of underlined words, so you have to take account of spaces that are ignored :-)
    – dave
    Commented May 9, 2021 at 12:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .