[TUHS] Algol 68 and Unix (was cron and at ...)

My knowledge of A68 comes from reading the official definition back in the day. It took effort to see the clarity of the design through the fog of the description. Until more accessible descriptions came along (which I admit to not having seen) it would have been a big barrier to acceptance. A68 was very much in the air (though not much on the ground) in the early days of Unix, as was PL/I. Although we had implemented and used PL/I for Multics, it was never considered for Unix due to Its size and the rise of other attractive languages during the 6-year gestation of Multics. BCPL had the most influence, particularly in its clever identity a[i] = i [a] = *(a+i).It was OK to write 2[x], which served to implement structs like this: field=2; field[x]=3. (Actually the BCPL indirection operator was not *. Dennis borrowed the more perspicuous *from the SAP assembler for IBM 700-series machines.) first he unwisely reversed their spelling, underestimating the inherent hazard of a=-b. He rejected A68's automatic dereferencing as too inflexible. He considered whether semicolons should be separators as in Algol, or terminators as in PL/I. (Separators are more convenient for macro substitution, but macros were not in the original design.) He also considered making statements and expressions mutually recursive as in A68. My recollection is that his choices were finally based on a guess about user acceptance--how many radical innovations would prospective users buy into. Perhaps Ken would have more to say about this, I tried to persuade Dennis to provide simultaneous assignments like a,b = b,a, In the end, the comma operator got hijacked for a partial realization of embedded statements.(We could still get parallel assignment by, interpreting the existing {a,b,c} syntax as an lvalue thus: {a,b,c}={b,c,a}.) Then came Steve Bourne, with real experience in A68. Its influence on the shell, including the story of do...done, has often been told. It shows up most vividly in the condition part of if and while statements. Doug