Talk:ALGOL 68

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
 

Discussion of Algol 68 wikipedia content/style[edit]

I propose to shorten the article considerably. In the present form it has a too defensive character. For my feeling, the references to Perl, Scheme, ML are not really helpful. Some criticisms don't need to be mentioned (operator priority discussion). --Glasreiniger 13:24, 26 Feb 2005 (UTC)

I'm not sure I agree the article needs to be shorter. In many ways it should be longer. But it could certainly be improved. It has that common problem that it has been added to in pieces by many people with new information, and has lost any unity and structure it might have had.
My thoughts are
  • Rename "Overview" (which it isn't) as "Notable language features". Make sure everything there is notable, and make sure it makes sense to someone who never saw the language before.
  • Rework "some vanitas" into "Notable language features" or lose it.

Hmm. Iff the article is shortened, this is a good candidate, too. Note the "iff". In the present state of the article it may expalin some of the shortcomings.

  • Criticisms should not be based on new insights; new insights don't belong.

Why not?

  • Comparisons with other languages may have a place, but are they original research? In any case the comparison with C++ is not factually accurate (e.g. C++ has formatted transput, surely, with printf/scanf) and may not add much to the article.

printf is not part of the language, contrasting to A68.

  • --- This does not change anything. The language together with its standard library is something the user has on start. So this whole set should be considered, if you want to compare. You would also say that Tcl does not provide Object-Oriented features, not even mentioning that it has several libraries that provide it. Please, try not highlighting in comparisons things that are "not supported in the core language" because for a particular language user this does not mean anything; such a user would like to know if he can just do some thing requiring this feature or not. Not only has C++ printf-s derived from C's standard library, but there is also provided Boost::format with richer facilities. Should you have it in a language, you can say that the feature is available, no matter how. I would be rather interrested with facilities, which MUST be done in the core language and, for example, C++ does not have it and it is hard to emulate it.

Ethouris

  • Variants needs to mention the important ALGOL 68C and ALGOL 68R. The first part of that section belongs under notable language features or nowhere. Proceduring is notable, I think, but must be defined.

Proceduring is *the* part of the language where the non-revised language failed, and it was noted. Proceduring, as defined in the in the non-revised language didn't work correctly. But removing proceduring was a really bad cure for that. It is easy to see, that a usable description could have been found, by the simple fact that adding some parentheses and "PROC BOOL:" in the source make the magic work (correctly!).

  • I'd like to see more on history and especially on discussions of the reason for its failure. http://www.cs.ru.nl/~kees/home/papers/psi96.pdf is a very interesting reference. "[The revised report] resulted in an exemplarily clear, precise and consistent description of anelegant and orthogonal language that was at its appearance already classical but dead.

Agreed.

  • An original insight that could be included if someone else published it: why would the commercial world implement a language from academia in the form of a report, which also included a minority report definining a different language? Suicide!

Notinasnaid 12:10, 28 Feb 2005 (UTC)

Let me comment on the last item: It wasn't suicide. --Glasreiniger 21:24, 28 Feb 2005 (UTC)

Let us try to make a good article, at least. If nobody complains, I am going to start making the article more concise, trying to use your hints.

New insights? At one time I found this rule as an adjunct to "no original research", i.e. "no original insights". I can't find it now!
The issue with proceduring is that it is not defined before it is discussed. I know what it is, but I don't think anyone who didn't would be left any the wiser. It is quite an interesting and unusual idea, and worthy of discussion.
Anyway, to follow another Wikipedia rule: "Be bold!" Notinasnaid 21:54, 28 Feb 2005 (UTC)

Implementation of Algol68[edit]

Concerning Algol68 being an academic language and already dead-at-birth: at Control Data Corporation we've built an almost complete implementation (only 1 or 2 items missing), commercially published around 1978 for use on 6000 and Cyber series mainframes. The resulting code was quite efficient, notwithstanding the often called "complexity" of the language.

Operators[edit]

Is the elem operator the same as the ⌷ operator, or was/is the "¤" from EBCDIC used?

Also: I kinda recall "somewhere" that in place of := and =: one could use ← and →. Am I getting mixed up with APL?

NevilleDNZ 02:01, 24 August 2005 (UTC)

The rectangle is called "window symbol" in the RR, it is used as elem operation symbol, yes (RR10.2.3.9b). The report does not define how the symbols are encoded. A different document (Hansen, Boom: The Report on the Standard Representation for ALGOL 68) tries to clarify how the symbols are represented in ISO646 and EBCDIC. This document discourages the use of most symbols not in the intersection of these symbol sets.

(C.5 Other characters: A portable program should be written entirely in worthy characters, becasue only these characters are available in all implementations). The digraph <- is not allowed in a68 as operator symbol, as in S-plus, e.g. because x < -1 and x <- 1 would easily be confounded. ->, though, could be used. Extensive use of exotic symbols is not typical for programs written in A68. --85.22.19.171 19:26, 26 August 2005 (UTC)

Have been skimming throught the Draft Final Report you pointed out online.... It seems that there is a whole pile of operators in the Draft Final Report I never even knew about. Check Pages 109... The FR allows .. as well as :, → in place of "of". Did this "I am guessing that this online version isn't the "Final Final Report". Looks like I have a bit more reading to do. (Ironically a similar -> made it into C/C++)
But it looks as if the semantics were inverse. Personally, I prefer C++ in this respect. You call the document "draft": AFAICS my prionted version of thsi is the final published report, but before revision. I never got in acquaintance with A68 before revision. So I cannot comment mcuh on this, except that I had preferred that proceduring (not as coercion) ahd survived.

--Glasreiniger 20:02, 26 September 2005 (UTC)

The American Standards Association (ASA, later to become ANSI) first published ASCII as a standard in 1963. ASCII-1963 lacked the lowercase letters, and had an up-arrow (↑) instead of the caret (^) and a left-arrow (←) instead of the underscore (_).
"1968 President Johnson issues order adopting the (newer) American Standard Code for Information Exchange (ASCII-1967) as a federal standard".
Hence Algol68 was straddles both ASCII-1963 and ASCII-1967 standards.
Ironically the ¢ (cents) symbol got dropped from the Amercian ASCII standard, but became part of the European Algol 68 standard.
NevilleDNZ 16:56, 25 November 2005 (UTC)
I also found the A*10**B symbols were 10 AND "\". And some strange operators I havn't figured out yet..., i.e. lws, ups, ctb, btb, ::, ct, ctab etc, with related APL characters...
¢ NevilleDNZ 17:23, 26 September 2005 (UTC) ¢

Hardware character sets and representation[edit]

I had look into unicode internals for this case. It looks as if the "base ten" symbol was the only machine written symbol of computer age which didn't make it into unicode. This should be changed. But, personally, I don't like unicode enough to feel engaged. It seems that, if anybody wants to make this into unicode, has to be prepared very well. Of course, the representation using two subscripts is sufficient to publish documents containing. But for this, Unicode subscript were superfluous as well. The origin of this symbol seems from British teletype code as variant to the backslash, and it has been used in the German TR440 computer central code ZC1 at position 141. --Glasreiniger 20:02, 26 September 2005 (UTC)

I used Algol68C on EBCDIC of IBM VM/CMS and ASCII of DEC10. There were no "exotic characters", but fortunately there were upper and lower case, otherwise Algol68 code would have looked worse the COBOL code. Clearly there was no Unicode back in 1968, so did the "exotic characters" only ever exist on paper, or were they sourced from some other pecular computer system? Also, if I recall right, a semicolon was also regarded a exotic to some character sets, hence Algol-W used a comma-dot, instead of a semicolon at the end of statements. (And hence maybe the : used in todays array slices x[1:3], possibly originated from x[1..3] which appears to be more natural)

CHA Koster tells in his memories about the making of ALGOL 68, that the writers of the Report had much fun in finding new symbols on the typewriter wheels, which were state of the art at that time.
The IBM 2741[1] Terminal (c. 1965), this must have been what Adriaan van Wijngaarden had been using before the Aug 68 meeting. (Then in 1975 for $20,000 you could get a IBM 5100 [2]). Maybe it was the IBM Code page was being used in the IBM 2741 alternatly Code page 293[3], or Code page 371[4].
Another Algol68 superset totally missing from wikipedia is Algol68+ But I suspect that was not often used outside of The Netherlands. It would be interesting to lists its character set as Adriaan van Wijngaarden had a particular interest here.
¢ NevilleDNZ 02:07, 24 September 2005 (UTC) ¢

The ¬ clearly entered via EBCDIC. I am kind of surprised the the ¢ was so extensively used in the actual RR, it is in EBCDIC, but not ASCII. But certainly any typewritter can do it with a C^H/.

Language semantics[edit]

On an aside, in fortran a declaration of "REAL REAL REAL" is legal, I am guessing Algol68 was trying to mimic this in its declaration syntax, eg by allowing "real real real;", (which contains spaces in variables, and reuse of "reserved" words/tokens). If this true?

In case of FORTRAN IV, spaces are not significant in any position except in H formats. Position is, though. That spaces in identifiers are allowed, is heritage from Algol60.

And on another aside, why did Algol68 have the IF .. FI, DO .. OD and CASE .. ESAC. But spoil every thing by using CO .. CO, and PR .. PR, no CO .. OC and PR .. RP?

Probably an oversight. Comments do not contain interesting stuff. But TNEMMOC would look rather strange. NIGEB, too. When I program A68, I don't use IF..FI very often. I prefer the short symbols ( | | ), anyway. But for DO..OD there are no short symbols. --Glasreiniger 17:19, 27 August 2005 (UTC)
TNEMMOC & TAMGARP probably wouldn't translate into Dutch very well either. ¢ NevilleDNZ 06:32, 28 August 2005 (UTC) ¢
It is little known, that the ALGOL68 Reports have been translated into German and Russian, possibly other languages, too. The termini technici like MOID have been translated also in the unrevised report, in case of MOID the German translation was MÖSCH, which is a contraction of MODUS and LÖSCH. For the RR only the text was translated. --Glasreiniger

(BTW: Every time I do a "do .. done" loop in borne shell I cannot help but think of someone (long long ago) shooting themself in the foot with the unix "/bin/od" command)

NevilleDNZ 20:03, 26 August 2005 (UTC)

On the CDC 63- and 64-character sets, where ":" was problematic or missing, ".." was a representation substitute. This may have given rise to the use of ".." in Pascal, which was also first developed for the CDC mainframe series. Notinasnaid 22:06, 26 August 2005 (UTC)

The Control Data computers with their 6bit characters are, of course, very restricted. The standard hardware representation for A68 declares 60 characters worthy. --Glasreiniger 17:19, 27 August 2005 (UTC)

Operators vs "Syntatic elements"[edit]

I noticed some laxness in the operator list. In Algol 68 "IS","ISNT" and their shorter forms :=: :/=: are not operators but special syntactical symbols like := . I am not sure whether correcting this would go to much into technical details. For now I just move the short forms from the implementation column to the original language column, where they belong. --Glasreiniger 11:27, 23 September 2005 (UTC)

I have found an argument, why it must be corrected: The priorities are wrong. These constructs don't have PRIO 4,. Effectively their priority is less than that of any opreator. Maybe putting them in a row with PRIO 0 and a comment is a good solution. --Glasreiniger 18:34, 23 September 2005 (UTC)

If I remember right :=: and :/=: were not part of the standard. BTW I dug the is and isnt operator pririties from the Revised Report, so the prio is = 4, isnt = 4; should be OK.

Sorry to disagree. But the is symbol is not an operator, it just loooks like one. The :=: was present in in unrevised report already. For the negated equal sign, two possibilities are provided in the RR: either the mathematical unequal sign or the digraph from slash and equal sign for operator and identity relation symbol. The not symbol is only used to construct operators. --Glasreiniger 18:07, 24 September 2005 (UTC)
Not a problem. I checked the RR that you put online, and you are right. So, I have effectively moved the :~=: "syntactic" elements to priority 0. I left the plusto, but removed the other timesto operators as I could not find them in the RR. I wish I had a copy of the Algol68C manual to see if the timesto were implemented there.
I have a copy of the Algol68C manual. If this is not available on the net already, I could perhaps make scans available. But, with no compiler for this implementation, this is not too interesting. Algol68C does not define or allow to define operators with assignation. These are automatically available for all operators where these are applicable. So, Algol68C has timesto and similar. I am not sure that the authors really thought much about the displace-formulas, how they call these, after looking this up. --Glasreiniger 15:57, 25 September 2005 (UTC)
Do you know the "official" priority of the uniary operators? esp not, as typically (in other languages) its priority is lower then that of arithmetic diadic operators.
In A68, all monadic operators have prio 10. The most likely troublespot is -1^n . Of course, it would be more natural to have all boolean operators at a lower priority than arithmetic.
I guess my interest in the article is not to create a reference, but to answer some of the questions on the origins of Algol68 of the kind a learner may ponder, Why this? why that? etc. And keep the reading relatively "light". Kind of a "extra lite Algol68" version of "The Annontated C++ reference manual". So feel to interject if anything I add is too heavy.

LALR parsers[edit]

BTW: did anyone ever write a parser (like YACC) for the language of the Revised Report eg. "REF to MODE NEST destination{a} : soft REF to MODE NEST TERTIARY"?

¢ NevilleDNZ 01:55, 25 September 2005 (UTC) ¢

Algol68 cannot be parsed by LALR parsers because the natural grammar is not LR1. One of the big troublemakers is, that a comma is allowed between declarations; so a variable declaration may follow a mode declaration; so you don't know whether a mode indicant at this place is a defining or applying one before seeing the equals sign. At least you need to know the priority before use, if you want to parse operator precedence in one run. The Algol68C restriction is sufficient for this case. I have written a YACC parser for Algol68 for the full language with this restriction myself. I cannot really claim that this is a faithful parser, because some of the syntactic restrictions are not enforced. They have to be honored in the sematic routines. --Glasreiniger 14:52, 25 September 2005 (UTC)
I seem to remember (and this is from a very long time ago, when I was thinking about writing a compiler), that one of the most challening constructs to encounter starts
op == ( mode...

where you don't know yet how to parse the ==. Is this a typed operator declaration for ==, or an untyped declaration for =? This may be misremembered, but something like this annoyed me for a long time. Notinasnaid 16:04, 25 September 2005 (UTC)

This is not the actual trouble spot, because in the typed op declaration the declared symbol comes after the modes: OP (INT,INT)BOOL == SKIP . IMHO it is allowed to restrict usage of = as defines-symbol not to be adjacent to operator symbols it can combine with.
But if you have MODE FOO = STRUCT(...), BAR = ... , you need to 2 tokens look-ahead to see the equal sign, before you can decide that the mode declaration continues; otherwise BAR could start a variable or identity definition. In my lexer this leads to the restriction, that after a boldtag in defining context only one blank is allowed. The comment in my Flex lexer calls this a quirk. A hand-written lexer could avoid this.
Note that the keyword MODE is nearly useless, because a parser powerful enough to cope with this is also able to know that FOO = STRUCT ... must be the begin of a mode declaration, anyway. --Glasreiniger 16:42, 25 September 2005 (UTC)

As an aside, Charles Lindsey, one of the editors of the Revised Report, lectured to me in the Manchester Department of Computer Science on Algol 68 around 1970. He worked on one of the early compilers and I seem to remember him saying that they considered parsing the language in reverse, i.e. starting with the last token. This is clearly possible, but I'm not sure if it was ever done nor what the complexity of the reversed grammar might be.

Resources[edit]

Online reports[edit]

I am not a member of ACM, here is the revised report [5], do you know if this PDF is produced from scanning paper, or from original electronic text/input (Maybe EBCDIC)?

The ACM version is just the image from scanning. I happen to be the one who has made the (first) revised report available online. http://vestein.arb-phys.uni-dortmund.de/~wb/RR/rr.pdf e.g.. There are also TeX, .html and .dvi versions. Karl Kleine has published the MR176 paper. I am quite sure that the symbols in my version are the correct ones for the report. Charles Lindsey himself has done some proofreading of my text. --Glasreiniger 17:44, 24 September 2005 (UTC)
One nice thing you could do (from the html), is imbed a URL pointing to the original scanned paper original. That way others can help spot OCR/scanner errors and email you fixes.

¢ NevilleDNZ 01:55, 25 September 2005 (UTC) ¢

I shall follow this hint. But the accessibility of an ACM document is seriously difficult. Though, there is an authentic machine readable RR available now, from Dick Grune in [[6]]. The unrevised report is at [[7]]--Glasreiniger 17:06, 25 September 2005 (UTC)
I mostly converted the RR to html (with a python script) today. ¢ NevilleDNZ 17:23, 26 September 2005 (UTC) ¢

If one looks, there are getting to be a lot of Algol68 resources on the internet.

¢ NevilleDNZ 02:07, 24 September 2005 (UTC) ¢

Algol68 Final Report special characters[edit]

i.e. The ∨, ∧, ¬(?), ≠, ≤, ≥, ×, ÷, ⌷, ↑, ↓, ⌊, ⌈ and ⊥ characters. APL2 keyboard stickers are available from IBM part number SC33-0604. They cost about $13 for a set of two.

¢ NevilleDNZ 16:58, 24 September 2005 (UTC) ¢

Just curious: The number of atoms in 0.012 kilogram of carbon 12 is known as Avogadro's number. It is approximately 6.0221415×10↑23 (2002 CODATA value). Does the RR still allow me to define this constant as follows:

  • real n = 6.0221415₁₀23;

⑽, ⒑, ⑩ do exist in unicode... something to do with the British wanting to support 12 pennys in a shilling. But the subscript 10 needs two characters.

Maybe we need to get the Working Group 2.1 on ALGOL68 to revise the RR to include/loby Unicode for 2005?? :-)

¢ NevilleDNZ 15:44, 25 September 2005 (UTC) ¢

IMHO there are enough reasons to do a formal proposal to unicode.org to include this symbol. It has been included in a German norm (DIN66006 IIRC), it has been discussed in ACM: comm.ACM 7 No 7(424,447), there called "subscript 10". Personally, I don't like Unicode enough to be engaged in this. A nice web page about codes includes it: ALCOR. But a better place to show this stuff should sougth, because it distracts from the programming language. And it is heritage from ALGOL58. --Glasreiniger 08:33, 28 September 2005 (UTC)
I kinda agree with you... for example, even without significant support for the official APL character set, the APL developers continued programming in APL using "other characters". After all character sets don't make a language. Beside if we want to add to wiki all the details of the language (including the 10), then we might as well replace the wiki-page with the Revised Report!! (I am allowed to be harsh as it was my suggestion)
The now realise that the 10 characterm appears in several standards. ALCOR of [ACM] (became DIN 66006 in Germany), GOST 10859 7 bit Cyrillic & Latin.
In GOST 10859/Cyrillic there appears to be various characters subsets giving greater text compression:
BTW: Why was the word "worthy" used... was it a pun?
NevilleDNZ 04:55, 21 October 2005 (UTC) ⍧
Ironically the APL keyboard that appears to be the defacto keyboard for Algol68/FR, can still be obtained from IBM even today.

I can see another mine-field just with Working Group 2.1 adopting a unicode version of Algol68. After all which asterix is the official Algol68 asterix, there are dozens in Unicode. Not to mention many ways of writting the number 10.

BTW: ThanX for telling me where the 10 came from. Needless to say I used Algol68 in ascii, and didn't even realise it existed until I read the whole RR.

NevilleDNZ 17:37, 28 September 2005 (UTC) ⍧

If you look VERY carefully into this part of the report, you may be be able to notice, that the label symbol is a slanted colon, in contrast to the routine symbol and the colon used in slicing. The alternative EXIT symbol should be a fat point. -- Glasreiniger 07:15, 29 September 2005 (UTC)
I did notice in the machine readable document that the label colon had been given a special name "lbl". I wondered if this was just a "throw back" the document formating softawre used. (BTW: does this document foram have a name?).
I also noted that there is something called a "thin". eg in RR at section 3.3 between [ & ] is a "thin":
thinspace, \, in TeX.
[ ] INT q = (1, 4, 9, 16, 25); STRUCT (INT price, STRING category) bike := (150, "sport"). 
My gut feeling was so that [] didn't look too much like a window character ⎕.

Here us a rough match of the RR name, and the unicode equiv that I found. I gave priority to the APL keyboard.

RR Name Unicode Name UC Char A68 base A68 vogon
"ttp" "subscript one"+"subscript zero" "₁₀" "\" E
"sge" "greater-than or equal to" "≥" ">=" GE
"sle" "less-than or equal to" "≤" "<=" LE
"ne" "not equal to" "≠" "/=" "~=" NE
"ct" "apl functional symbol left shoe stile"/"cents" "⍧"/"¢" # CO
"flr" "left floor" "⌊" LWB
"clg" "left ceiling" "⌈" UPB
"box" "apl functional symbol quad" "⎕" ELEM
"slice" ../‥  :
"not" "not sign" "¬" "~" NOT
"sq" "division sign" "÷" "/" OVER
"sx" "multiplication sign" "×" "*" TIMES
"tip" "up tack" "⊥" I
"nl" "left-pointing double angle quotation mark" "«"
"ng" "right-pointing double angle quotation mark" "»"
"nil" "ring operator" "○" NIL
"up" "upwards arrow" "↑" ** UP
"dwn" "downwards arrow" "↓" DOWN
"hy" "hyphen" "-"
"or" "logical or" "∨" OR
"and" "logical and" "∧" & AND
Unicode / Final Report (1968)
"rightwards arrow" "→" OF
"box drawings light arc up and right" "╰" LWS
"box drawings light arc down and right" "╭" UPS
∙/•/∎ EXIT
LWS and UPS are the lower/upper state operators from the Algol681/FR.
BTW: Look at ALL these unicode characters for asterick: "✢✣✤✥✦✧✩✪✫✬✭✮✯✰✱✲✳✴✵✶✷✸✹✺✻✼✽✾✿❀❁❂❃❄❅❆❇❈❉❊❋". Now you know why I priotised first the APL characters. ☺. Me thinks that asking for just 1 "subscript ten"=₁₀ from the unicode guys would be a good idea to counter balance all the astericks!
I had totally forgotten about the "nil" symbol "○" (It is not in Algol68C ascii/ebcdic).
Unicode also has several logical and/or symbols... I guess usage of other codes (eg now Unicode) was seen as site specific. Making Algol68 Unicode Ready. ☺
Can you point me to a scanned/online version of the RR. AND Was SKIP officially a "~", or a "?"?

NevilleDNZ 09:32, 29 September 2005 (UTC) ⍧

The original is very bad; and AFAIK there are no real good prints at all. The report has been published photomechanically from bad sources. Even the microfiche version is not better. The combination of Dick Grune's version and my re-edition (the .dvi or .pdf, not .html) do a much better job. IIRC, the question mark is Algol68C for skip. --Glasreiniger 11:52, 29 September 2005 (UTC)
I could not access the document, a html permission problem. I know Victoria University has the paper Algol Bulletin, maybe they have an original RR. I can search the local universities. Actually the cheif reason I want to look is to check to see what the "strange" characters look like in print. I had to laugh, Algol_60 (http://eli-project.sourceforge.net/a60_html/a60.html) has "subscript 10" also, but they gave up and simply called it "E". As you suggest, somewhere in Europe subscript 10 was important... in the 1960s.
BTW: I tried emailing you, but got no reply.
Sorry. The permission is fixed now. --Glasreiniger 11:01, 21 October 2005 (UTC)
NevilleDNZ 09:39, 5 October 2005 (UTC) ⍧

Re structuring this document[edit]

So far, I have added a tiny section on the transput, and a tiny bit to the section on operators, and some code for parallel processing. They seem to fit in OK. There is not much mention about bits and bytes and such representations. FR vs RR and Extensions etc

Already we have reached the 32k recommended article size. Is it time for a revision/pruning? What have we missed that is notable? Having said that it looks basically OK to me so far.

One book I read years ago on A68 could have its sections read "horizontally and vertically" out of a grid. This highlights that A68 was designed to be orthogonal. Do U know the Author/Title of this book? Could we structure an article like this?

NevilleDNZ 17:37, 28 September 2005 (UTC) ⍧

The book is Lindsay and van der Meulen's Informal Introduction to Algol 68. It would be interesting to structure the article that way, though I'm not sure where one would fit some of the political aspects of the language's history in that structure.

One thing that is definitely missing from the article is a discussion of "triple ref technique" which is possible only because the language allows references to non-heap objects. A Rosetta Stone-style listing of linked list manipulation in ALGOL 68, Pascal, and C might be the way to show the technique's advantages.

A discussion of the triple REF technique is needed, indeed. IMHO this hasn't do too much with heap vs. non-heap, as Algol-68 can easily be implemented without LOC at all (just make all allocations on heap). I have prepared some variations on the theme in [[8]]. The file queuea.a68 is due to Andy Walker (discussion in news:comp.lang.misc) except for the complaint in the commentary, of course. queueb.a68 changes the original file by lifting the REF up to mode LIST. queuee.a68 makes the algorithm parallel-safe, hopefully. I like queuef.a68, because it uses operators instead of functions. In queueg.a68 I modified the program to avoid triple REFs. Yes, this is easy: Just wrap one of the levels into a STRUCT. For syntactical reasons, a second field dummy in this STRUCT is needed. --Glasreiniger 13:57, 14 February 2006 (UTC)
Ack, you're absolutely right. The point is that unlike Pascal, which only allows pointers to records, Algol 68 allows references to things of any mode, including ref ref amode (i.e. variables of type ref amode, in particular those where references to heads of lists or roots of trees are stored), hence the name. My mistake.

Just a quotation ...[edit]

I came across the following, years ago. (I won't vouch for its precision, though.) I don't agree with it, but, here it is anyway:

   "If PL/1 is a fatal disease, then is not Algol 68 just _capital punishment_?"

12.216.178.59 00:06, 20 February 2006

This quote might be a pun on case-stropping where the published form "begin real pi=4*atan(1) end" would be written as case-stropped "BEGIN REAL pi=4*atan(1) END". I remember that case-stropping (changing case for "Syntatic elements", MODEs and OPerators) was a pain on keyboards that had only caps-lock (ansi) and but useful on shift-Lock keyboards (IBM). I finally discovered a keyboard that had both manufactured by Tandem-Computers.

NevilleDNZ 11:48, 10 July 2006 (UTC)

wiki2wirthy.py - convert html4 markup and unicode to Algol68 "Wirthy" 7-bit characters[edit]

#!/usr/bin/env python
## -*- coding: utf-8 -*-
# wiki2wirthy.py - convert wiki markup and unicode to A68 "Wirthy" characters
# use this to dewikify a68 source, and convert unicode operators into UPPERCASE tokens
# 20061115 v0.2: add the original operators from the final report.
# 20070613 v0.3: add the html4 character set
import sys, re
 
import codecs
enc, dec, rwrap, wwrap = codecs.lookup('utf-8')
 
def forall_argv(process_file,argv=sys.argv[1:]):
  if len(argv)==0: # then
    process_file(rwrap(sys.stdin))
  else:
    for file in argv: # do
      file=open(file,"r");
      process_file(rwrap(file))
    # od
  # fi
# end forall_argv
 
re_markup=re.compile("(<[^>]+>|[&]nbsp;)",re.IGNORECASE);
re_ul=re.compile("(^<[bu]>$)",re.IGNORECASE);
re_lu=re.compile("(^</[ub]>$)",re.IGNORECASE);
 
wirthy={ u"¢":"#",
  u"₁₀":"E", r"\\":"E",
  u"≤":"<=", u"≥":">=",
  u"≠":"/=",
  u"[⍧¢£]":"#",
  u"⌈":"UPB", u"⌊":"LWB",
  u"⎕":"ELEM",
  u"[.][.]|‥":":",
  u"¬":"NOT",
  u"÷":"/", u"×":"*",
  u"⊥":"I",
  u"[○∅]":"NIL",
  u"↑":"UP", u"↓":"DOWN",
  u"∧":"AND", u"∨":"OR",
  u"→":"OF",
  u"[☩✠᛭]":"$", # [[ALCOR]]
  u"╭":"UPS", u"╰":"LWS",
}
 
re_wirthy=dict( (re.compile(char),"_"+fix+"_") for char,fix in wirthy.iteritems() );
 
import htmlentitydefs
""" additional ALGOL characters/operators from html4 std
  cent ¢    pound £  yen ¥    euro €    curren ¤
  plusmn ±  minus −  times ×  divide ÷  oplus ⊕  otimes ⊗        
  larr ←    uarr ↑   rarr →   darr ↓    harr ↔   crarr ↵ 
  and ∧     or ∨     not ¬   
  cong ≅    asymp ≈  prop ∝   ne ≠    
  empty ∅   infin ∞ 
  perp ⊥    lceil ⌈  rceil ⌉  lfloor ⌊  rfloor ⌋        
  equiv ≡   sup ⊃    nabla ∇  loz ◊     deg °    # [[GOST 10859]] ALGOL characters
  radic √   part ∂   int ∫    prod ∏    sum ∑    # bonus operators
"""
re_html4=dict((re.compile("&"+name+";"),u"%c"%code) for name,code in htmlentitydefs.name2codepoint.iteritems() );
rev_html4=dict((re.compile(u"%c"%code),"_"+name.upper()+"_") for code,name in htmlentitydefs.codepoint2name.iteritems() if code>127);
re_depad=re.compile("_ *| _|$_")
 
stdout=wwrap(sys.stdout)
stderr=wwrap(sys.stderr)
def wiki2wirthy(file):
  markup=True;
  in_ul=False;
  for line in file.readlines():
    markup=not markup;
    for token in  re_markup.split(line):# do
      if not markup: # then
        if in_ul: token=token.upper() # fi
        for re_char,fix in re_html4.iteritems():  token=re_char.sub(fix,token);
        for re_char,fix in re_wirthy.iteritems(): token=re_char.sub(fix,token);
        for re_char,fix in rev_html4.iteritems(): token=re_char.sub(fix,token);
        token=re_depad.sub(" ",token) # a crude tidy up
        for c in token: # do
          if c>"~":  # detect unconverted unicode and dump
            stderr.write("unknown character: "+c+"\n");
            stderr.write("Error: "+`[ c for c in token]`+"\n");
            break
          # fi
        # od
        stdout.write(token);
      # fi
      # handle wiki <markup>
      elif re_ul.match(token): in_ul=True
      elif re_lu.match(token): in_ul=False
      # fi
      markup=not markup
    # od
  # od
# end wiki2wirthy
 
if __name__=="__main__": forall_argv(wiki2wirthy,argv=sys.argv[1:]) # fi

My apologies to compiler writers (and python unicode experts) for this terribly crude parser... For wot is it wirth... I declare the above code to be GPL.

NevilleDNZ 13:07, 13 June 2007 (UTC) revised for html4

ALGOL 68 definitely not the ancestor of C, C++, sh or bash[edit]

  1. C++ was originally a front end built on top of C and drawing heavily on SIMULA-67 (which obviously predates ALGOL 68).
  2. C was a successor to B, itself a trimmed-down version of BCPL, itself a trimmed-down version of CPL, which again predates ALGOL 68
  3. sh and bash have nothing at all to do with ALGOL 68 apart from being procedural langauges.
  4. C, sh and bash are weakly typed.

99. On the other hand, both SIMULA-67 and CPL draw heavily on ALGOL 60. ALGOL 60 is the ancestor. ALGOL 68 is, as far as I can tell, more of an evolutionary dead end. -Dmh 19:01, 29 January 2007 (UTC)

re: Is ALGOL 68 an ancestor of C, C++, sh or bash?[edit]

1. re: C++

  • "Stroustrup borrowed successful features from other older languages. As a result, C++ incorporates the concepts of classes and virtual functions from Simula67. C++ borrows the idea of operator overloading from Algol 68. These features are an important part of the support that C++ provides for object-oriented programming.[9]"

2. Re: C

Steve talked Dennis into adding void as a type in C. It saved the instruction loading register for return value. Also when Steve got to the lab C types were like PL/1 namely offsets from any base you liked. They changed to A68 types but be the specific reason for this change is now lost. A few other A68isms ended up in C. (Subsequently these A68isms made their way into C++).

3. Re: Bourne Shell

  • The - Bourne shell source telling an interesting story of Algol68's influence on the Bourne shell. Bourne reused portions of ALGOL 68's "if ~ then ~ elif ~ else ~ fi", "case ~ in ~ out ~ esac" and "for ~ while ~ do ~ od" clauses in the common Unix Bourne shell syntax. Moreover - although the v7 shell is written in C - Bourne took advantage of some macros[1] to give the C source code an ALGOL 68 flavor.

I would suspect (but I cannot back it up with a quote) that the parallelism in the Bourne shell was a direct result of the PAR clause in Algol68. eg

  • Shell: (sleep 10 ; date ) & ( sleep 20; date) & (sleep 30; date)
  • Algol68: PAR ( (sleep(10); date ) , ( sleep(20); date) , (sleep(30); date) )

However Algol68 didn't get pipes until arriving on Unix, and the pipe behavior is not part of the standard.

Shell and Algol68 are unusual in that both are early examples of concurrency which is mostly absent from other standard languages of the time. (PL/I had/has the TASK keyword)

4. Re: C, sh and bash are weakly typed.

5. Re: ADA Influences

Extract from: http://archive.adaic.com/pol-hist/history/holwg-93/2.htm (source: portal.acm.org/ft_gateway.cfm?id=1057816&type=pdf)
  1. Without exception, the following languages were found by the evaluators to be inappropriate to serve as base languages for a development of the common language: FORTRAN, COBOL, TACPOL, CMS-2, JOVIAL J-73, JOVIAL J-3B, SIMULA 67, ALGOL 60, and CORAL 66.
  2. Proposals should be solicited from appropriate language designers for modification efforts using any of the languages, Pascal, PL/I, or ALGOL 68 as a base language from which to start. These efforts should be directed toward the production of a language that satisfied the DoD set of language requirements for embedded computer applications.
Ada - DoD HOLWG, Col Wm Whitaker, 1993

I don't know what the complete list of functionality originally from ALGOL 68 is. Maybe concurrency, operators, overloading & strong typing. These were mostly missing from ALGOL 60.

So I can say with certainty that Algol68 influenced C, to quote "there was influence, much of it so subtle that it is hard to recover even when I think hard." -Dennis Ritchie, 18 June 1988

99. re: Evolutionary Dead end.

  • IMHO: Algol68 was an experiment in both language design, and in collaborating in language design. Both of these disiplines were in their early stages of evolution .
Certainly the prominent compiler writers for ALGOL 60 were prominent in the ALGOL Bulletin "mailing list", but strangely none of them were on the actual core ALGOL 68 team. Maybe this caused C99's ratification to be delayed 31 years? :-)

NevilleDNZ 23:36, 7 February 2007 (UTC)

a 2nd re: to dmh[edit]

IMHO you are right in A68 being a dead end. Now we know that it was a mistake to introduce pointers into a HLL. But AFAIK till the advent of Java this has not been corrected in the more successful languages.

Algol 68 is a language with precise garbage collection and type-safe access to memory so, like Java, it has references, not pointers. A reference is something that can be made to refer to another value. References are needed for recursive structures such as trees and linked lists, and for modifying variables. Since all values in Algol 68 are immutable, references are how Algol 68 implements mutability. There is no pointer arithmetic or pointer casting in Algol 68, since that would violate its type system and memory model. — Preceding unsigned comment added by 72.196.148.37 (talk) 00:10, 14 May 2012 (UTC)

Sh is not comparable to a programming language. But the facts, which Neville reports, are correct, at least in the main parts. One exception is the parallelism. The & Operator has been in use in V6 Unix, but not the if - fi bracketing construct, which is due to Bourne, who has been one of the first A68 compiler writers.

Agreed, postfix "&" would appear to predate A68's influence on the Bourne shell in v7. A coincidence only! :-( The "&" is certainly unique in both it's simplicity and similarity. It would be interesting to know what the inspiration for the v6 "&" was. NevilleDNZ 19:35, 8 February 2007 (UTC)
Another clear influence is the lack of distinction between statements and expressions in /bin/sh. Rp (talk) 09:45, 14 August 2010 (UTC)

It is simply a misunderstanding of the article text, if you read the wording heritage as being ancestor. --Glasreiniger 14:16, 8 February 2007 (UTC)

References[edit]

  1. ^ Bourne, Steve (1979-01-12). "mac.h - Macros used by Bourne to structure C like Algol68C". AT&T. Retrieved September 9 2006.  Check date values in: |accessdate= (help)
  2. ^ "A Shorter History of Algol68". Retrieved September 15 2006.  Check date values in: |accessdate= (help)

Footnote 10 needs editing and the Wikipedia mechanism seems broken. The broken reference should perhaps be replaced by www.nunan.fsnet.co.uk/algol68/pame.pdf . I have spent 30 min researching how to report the problem to Wikipedia, without success. — Preceding unsigned comment added by NormHardy (talkcontribs) 21:40, 11 December 2010 (UTC)

Peter Craven of Algol Applications Ltd and A68C[edit]

Here is the reference for Peter Craven's Algol68's branch:

Murdoch states: "Peter Craven of Algol Applications Ltd made a version of A68C that was interactive (did incremental compilation, permitted no forward referencing)"

I will try and clarify. But I suspect CJC has the trump card.

NevilleDNZ 07:33, 6 March 2007 (UTC)

Appears the source quote was mis-read. The quote is: "The execution model is stack based, using separate static and dynamic stacks as in Algol68C, and all expressions are evaluated on the stack." i.e. "as in Algol68C."

I will see if I can get exp=667 corrected.

NevilleDNZ 07:47, 6 March 2007 (UTC)

Recent compiler work[edit]

2002: Compiler / MMIX / NYU[edit]

In 2002 a NYU's Computer Science Ph.D. Candidate Antonio R. Nicolosi created a boot strap compiler for Algol68Nix.

NevilleDNZ 03:38, 13 April 2007 (UTC)

2000: Interpretor / Linux&DOS / Rutgers University[edit]

Not all the exotic features are implemented. In particular there are no semaphores, formats and parallel-clauses.

NevilleDNZ 01:43, 1 December 2007 (UTC)

1993: portable compiler / CWEB / univ-poitiers.fr[edit]

A portable Algol 68 compiler written in CWEB.

NevilleDNZ 03:05, 10 May 2007 (UTC)

A68S[edit]

Note, that there are two different beasts coming with this name: The a68s system which is available from the Unix Heritage Society for Unix-V7, see link to ALGOL 68S, and the compiler for Amiga etc. (add Atari ST and Ultrix-32 to the systems supported by this one) distributed by C.H.Lindsey. As I understand Lindsey's description they have a common ancestor. http://mirror.cc.vt.edu/pub/projects/Ancient_Unix/PDP-11/Applications/ --Glasreiniger 15:40, 3 December 2007 (UTC)

C++[edit]

First, the C++ code that has "the similar effect" to the new mode declaration is not exactly idiomatic C++. Why define a POD as a class rather than a struct, therefore requiring "public:", which is almost never written inline as in the example?

Meanwhile, in the comparisons, some of the most important differences are completely missed (e.g., separate compilation, templates, classes, RAII, exceptions, standard library vs. parallel processing, multi-dimensional arrays), while many of the listed differences are either not true or misleading.

It's claimed that C++ doesn't have:

  • garbage collection: But it does have refcounting (e.g., tr1::shared_ptr), with the usual advantages and disadvantages, and it can be used to collect all kinds of garbage (not just memory).
  • formatted transput using complex formatting declarations: C++ (with the standard library) has C's printf/scanf family, which has complex formatting embedded within the format string; these aren't syntactically integrated with the language (and in fact are interpreted at runtime rather than compile), but they're nevertheless roughly equivalent. C++ also has iostreams, which are syntactically integrated, albeit more verbose.
  • assignment operation symbol (to avoid confusion with equal sign): C++ spells the "equal sign" as "==", therefore the assignment operator can be "=" without confusion. (C++ spells constant initialization the same as assignment, while ALGOL 68 spells it the same as equality, but it's debatable which is more confusing.)
  • arrays (and slice operations on them, but in layered libraries): C++ does have arrays; it doesn't have slice operations; I don't know what layered libraries means in this context.
  • CASE expressions: No, but it does have case (switch) statements, which ALGOL 68 doesn't have (and the usual advantages and disadvantages of each apply).
  • nonlocal GOTO: What about setjmp?

While it's claimed that ALGOL 68 doesn't have:

  • overloaded procedures (in contrast to operators): True, but new operators can be defined.
  • explicit memory allocation and deallocation: Actually, it does have explicit allocation, with the "heap" modifier. It just doesn't have explicit deallocation.
  • textual preprocessing (header files): It's not just header files; it doesn't have textual macros or conditional compilation based either.
  • hierarchical classes: In fact, ALGOL 68 doesn't have real classes at all, so this is hardly surprising.

There are other features missing from C++:

  • parallelism (C++ can use platform-specific libraries such as pthreads--but even with these its memory model generally does not allow correct parallel programs to be written)
  • discriminated unions
  • case switching on unions
  • identifiers with spaces (not necessarily a bad thing to lack)
  • statement lists in loop conditions (although comma expressions can often fake this)
  • multiple-valued expressions (although see tr1::tuple and tr1::tie)
  • flexible arrays (although see std::realloc and std::vector)
  • variable-length array parameters (but again with the std::vector, or you can fake it by passing a separate length param)
  • multi-dimensional arrays (arrays of arrays are close, but not the same)
  • uniform initialization syntax (compare aggregates vs. classes with constructors)

And missing from ALGOL 68 (although some of these were included as extensions):

  • separate compilation (which lets you fake modules and libraries, as C and C++ do)
  • a large and useful standard library
  • templates (generics, metaprogramming, etc.)
  • class-oriented features (methods vs. static functions, constructors, etc.)
  • destructors/RAII
  • object-oriented features (dynamic polymorphism, inheritance, etc.)
  • exceptions (try/catch/throw)
  • namespaces
  • default parameter values
  • varargs
  • declaration/definition distinction
  • case switching on non-contiguous integers (and applying the same statement to multiple cases, and fall-through)
  • complex for loops (for (Node *p = head; p; p = p->next) { ... })
  • declarations in control statements (see above, and if (Node *p = (tail && tail->next)) swap(p, tail);)
  • true binary I/O
  • const reference (and pointer and, for that matter, value) parameters
  • overloading on constness
  • wide chars and strings
  • bit fields
  • operators equivalent to ^, ~, etc.

The corresponding section could presumably be fixed to be more complete and correct, but I question how useful it is in the first place. --75.36.138.40 10:38, 10 May 2007 (UTC)

A detailed comparison would be out of place in the ALGOL 68 article. (It is already 54k long)

In April I copied the comparison between ALGOL 68 and C++ into Comparison of ALGOL 68 and C++. I will remove it entirely (save for a link) from the A68 article. You (or I) can to insert your points above into Comparison of ALGOL 68 and C++, maybe with some details indicating if the feature is part of the C standard, C++ standard, a A68 revised standard, in a std/non-std library, or part of an implementation based extension. I am thinking a table format would work best.

You and I are probably the only people on the planet to worry about this, but I am keen if you are?

NevilleDNZ 08:34, 13 May 2007 (UTC)

I dont know what the original source for that particular comparison list. Hence even if we reuse it and expand on it in Comparison of ALGOL 68 and C++ we will have problems with Wikipedia:Attribution. Do you know of any "official" comparison? (eg. There is a Algol68 to Pascal comparison done by Andrew S. Tanenbaum).

NevilleDNZ 09:42, 13 May 2007 (UTC)

Having created this comparison, let me comment on this. As it is not from a verifiable source, it probably has to be deleted from the article. This comparison was solely intended to be a service for the uninitiated reader of the article about a historic language, which was likely to be forgotten at all. For the correctness of the claims you should distinguish between the language and any software system which can be built using the language. Garbage collection, e.g., is part of the language in Algol68 (and other programming languages like Java, Haskell, Lisp etc.), but not of C++. The goal of this list is not to discuss advantages or disadvantages, but just to explain what Algol68 is. A switch statement, e.g., is not at all comparable to a CASE expression, because it cannot be used in a formula. A68 does not have "identifier with spaces", it allows to write every identifier with spaces instead. I consider this form of polymorphism being not a good thing, too. --Glasreiniger 09:19, 14 May 2007 (UTC)
I removed the wrong claim that A68 does not explicitly allocates memory. Regarding the Pascal comparison: The main disadvantage of this is that Pascal was not intended to be used for production programming by its creator, its main design goal was teaching. The many fixes needed in real Pascal use make it difficult to distinguish between the language dialects. In contrast, both C++ and Algol68 claimed to be programming languages to be used.
The unkonwn contributor's comment on separate compilation has a very good point. Indeed, the lack of this is a big deficiency in A68, but: the solution of C++ is very clever, but mostly delegated to the host operating system by name mangling. At the time of A68, external symbols were restricted to be VERY short, sometimes only 6 chars; so it is not surprising that this way was not explored. Certainly A68 doesn't have wide char support, but C++ (as a language) neither did have (at least not in the earlier stages). In A68 it would be trivial to extend the language to allow LONG CHARs, but it can be argued that all characters in A68 could be wide chars as A68 chars are not defined being of length 8 (indeed, on many installations they had only 6 bits) as well.

--Glasreiniger

I always imagined that A68 was CharacterWidth agnostic. Esp it was planned to be used on 6-bit, 7-bit and 8-bit platforms. Will scan the Revised report for hints.

re: "identifier with spaces" - recall a quote (I cannot recall from exactly where) saying that after 2000 years of civilisation humans put spaces between words, and so too machines should be made to recognise spaces. (Ironically we have since evolved into CamelCase :-)

NevilleDNZ 10:03, 14 May 2007 (UTC)

Indeed, A68 ist charwidth agnostic, mostly. The RR defines the operators ABS and REPR to convert to and from INT. There is a prelude constant maxabschar defining the largest convertible integer, and it defines a minimal set of glyphs that must be present in the char set. But OTOH there are the conversions between BYTES (which may be available for different sizes), which assume that the length of CHARs converted to BYTES is a linear function of the charlength. This assumption is not valid for UTF-8. Anyway this could be cured without changing the language. Just supply prelude functions for support of the conversions needed.

One more thought about the attribution problem of this comparison. IMHO the facts reported in the comparison are easily verifiable by going down to the language definitions. So the only original research contained in the comparison is the selection of features mentioned. This should be acceptable for an encyclopedia. --Glasreiniger 12:47, 14 May 2007 (UTC)

Gomma?[edit]

The links to the external page (labelled 'Gomma') is broken. Searching the revised report only mentions that they are not included in the report. Apparently a reference to finnigan's wake, and supposedly allowing the use of semicolon instead of commas, is it an important concept? Is there a better link to replace the (broken) one? Google seems to only return either the revised report, this wikipedia page (or cut-and-pastes to/from it) or references to rubber. If it's not an important concept, the links (and mention of it) should go - if it is, then it needs exanding! Slothie 10:37, 15 June 2007 (UTC)

I found https://groups.google.com/group/comp.lang.misc/msg/03af5063e1662d4d The concept is actually quite important. The original language would allow the compiler to evaluate the arguments to a function call in any order, while the gomma would force the ordering. Something like this:

function(arg1, arg2 plus 1, arg3 plus 2)

The compiler is free to process arg1, and the sums arg2 plus 1 and arg3 plus 2, in any order. If there's a need for defined order, the gomma is used:

function(arg1; arg2 plus 1; arg3 plus 2)

Cheers! - Sodabrew 02:09, 24 January 2012 (UTC) — Preceding unsigned comment added by 66.54.159.98 (talk)

ALGOL 68 talk page tag & Category:User_ALGOL_68-4[edit]

I am sure that I am not the only ALGOL 68 programmer still kicking the dust.... So...

Algol68.png-4 This user programs in ALGOL at an expert level.

Here is a tag that can be put on ALGOL 68 contributors user page.

I have contributed some ALGOL 68 sample/example code to rosetta code... These are nothing fancy. http://www.rosettacode.org/rosettacode/w/index.php?title=ALGOL_68

Does anyone have some real ALGOL 68 code squirreled away on old tapes in the attic that could be contributed?

The 40th anniversary is coming up in December 2008. Anything simple planned in Munich? I hear Munich beer is rather good.

Here are now some online notes by Edsger W.Dijkstra on the subject of Algol-68. It is useful to see ALGOL-68 from his point of view: http://www.google.com.au/search?q=site:www.cs.utexas.edu/~EWD+algol-68

NevilleDNZ (talk) 15:43, 22 February 2008 (UTC)

Dijkstra?[edit]

I wonder why Dijkstra (and Hoare, for that matter) is listed as a designer of Algol 68. Neither of their names appears in the Report or Revised Report introduction. Looking for "Algol 68" in Dijkstra's EWD papers turns up some early words of concern, and some later words of total disgust -- nothing that would suggest he was involved in its creation. It might be, though I can't see specific evidence, that he was involved in the early days of the work to create a successor to Algol 60. That certainly would fit his background. But that doesn't mean he was involved in the creation of what actually emerged. Paul Koning (talk) 20:26, 20 August 2009 (UTC)

In "A History of ALGOL 68. History of Programming Languages-II"[1] both Dijkstra and Hoare are listed as active members: Fritz BauerHans BekicEdsger Dijkstra† • Fraser Duncan† • Jan Garwick† • Gerhard GoosTony Hoare† • P.Z. IngermanKees KosterPeter LandinCharles LindseyBarry MaillouxJohn McCarthyJ.N. MerrierPeter Naur‡ • Manfred PaulJohn PeckWillem van der PoelBrian Randell† • Doug RossKlaus SamelsonGerhard Seegmüller† • Michel SintzoffW.M. Turski† • Aad van WijngaardenNiklaus Wirth‡ • Mike Woodger† • Nobuo Yoneda; †Signatories to the Minority Report. ‡Resigned after [MR 93].

Notwithstanding this, maybe there is a better term then "Algol 68 designers" for Dijkstra and Hoare. "Algol 60 designers and active working group members" maybe?

NevilleDNZ (talk) 21:29, 29 September 2009 (UTC)

Stuff removed from Boolean data type article[edit]

The following section was removed from the article Boolean data type:
begin removed text



An actual extract from the ALGOL 68 language specification (page 177) where the Boolean operators are defined:

10.2.2. Operations on Boolean Operands

  • op ∨ = (bool a, b) bool:( a | true | b );
  • op ∧ = (bool a, b) bool: ( a | b | false );
  • op ¬ = (bool a) bool: ( a | false | true );
  • op = = (bool a, b) bool:( a∧b ) ∨ ( ¬b∧¬a );
  • op ≠ = (bool a, b) bool: ¬(a=b);
  • op abs = (bool a)int: ( a | 1 | 0 );


end removed text
Is there a place for this text in the Algol68-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 00:35, 31 December 2009 (UTC)

Algol68 on the BESM-4?[edit]

http://www.forumavia.ru/forum/6/9/5951042760252256152331268822069_2.shtml?topiccount=84

English> then was Algol-68 for the BESM-4, did not last long, because liked Fortran on EU-1020, EC-1022, EC-1033 (Diploma in writing on EC-1033 for cruise missiles, and the research was to caisson Mrii, then BESM-6, already at work, there was Fortran-77 and Algol...
Russian> потом был Алгол-68 на БЭСМ-4, недолго, ибо очень понравился Фортран на ЕС-1020, ЕС-1022, ЕС-1033 (диплом писал на ЕС-1033 по крылатым ракетам, а НИР была по кессону Мрии, потом БЭСМ-6, уже на работе, там был Фортран-77 и Алгол...

NevilleDNZ (talk) 04:31, 20 March 2010 (UTC)

s/Perl/Lisp/[edit]

I changed the reference to Perl in the quoted text below to a reference to Lisp instead.

  (int sum := 0; for i to n do sum +:= f(i) od; sum)

Note that, being an integer expression, the former block of code can be used in any context where an integer value can be used. A block of code returns the value of the last expression it evaluated; this idea is present in Perl, among other languages.

The notion of blocks that return their own values is not as strongly present in Perl as the text suggests. The discrepancy is so strong, that Perl isn't even a good example of a programming language that implements this concept. For example, the following is NOT valid Perl code:

  $x = { $sum = 0; for(my $i=0; $i<$n; $sum += f($i), $i++) {}; $sum; };

The only place you can implicitly return a value in Perl is at the end of a function definition, and in blocks that are accepted as parameters to specific Perl builtin commands.

Lisp, on the other hand, has expression-context constructs that bear much stronger resemblance to the ones described for Algol 68. For example, the Algol 68 loop above can be translated statement-by-statement into Lisp like this:

   (let ((sum 0))
       (loop for i from 0 to n do (incf sum (f i)))
       sum)

..and the note about the Algol 68 block being usable anywhere an integer can be used is also true of this LET block. The LOOP itself is an expression, and could be rewritten so as to eliminate the need for the LET block or the SUM variable.

75.186.5.185 (talk) 05:59, 2 January 2011 (UTC)

True. Perl was introduced because it freely allows statements to be used in expression contexts, unlike many languages, but as you write, it does not allow blocks of statements to be used in statement contexts. instead requiring an explicit conversion with do:
  $x = do { $sum = 0; for(my $i=0; $i<$n; $sum += f($i), $i++) {}; $sum; };

What the heck does that mean?[edit]

The opening paragraph...what in the heck does any of that mean to the average reader? Is there someone who can translate all that into layman-ese? 64.186.231.74 (talk) 00:57, 27 March 2011 (UTC)

It all seems pretty clear to me, but ALGOL 68 was my first programming language. Can you please explain what isn't clear to you and what, in this context, you consider to be a layman? Someone who has some idea of what a computer is? Someone who can read English? Without more specific questions it's very difficult to guess what sort of improvement you're looking for. Rp (talk) 22:27, 27 March 2011 (UTC)

Proceduring[edit]

This Text:

As defined in ALGOL 68, it did not work as expected, for example in the code:

if false andf ( print ("Should not be executed"); true)
then ...

against the programmers naïve expectations the print would be executed as it is the result of the enclosed-clause after andf that was procedured.

fails to explain that

if false andf proc bool: ( print ("Should not be executed"); true)
then ...

would have worked. So the fault is not proceduring, but the wrong description in the unrevised report which fails. --Glasreiniger (talk) 06:47, 12 April 2011 (UTC)

Use of 'DECIMAL EXPONENT SYMBOL' (U+23E8)[edit]

Is this correct? If so, why is there no glyph for it? Attys (talk) 00:51, 9 June 2011 (UTC)

'DECIMAL EXPONENT SYMBOL' is part of "The Unicode Standard 6.0"

I am not sure which OSes use Unicode6.0.0, it could be that you need to upgrade, or download DecimalExponent.ttf and install:

NJoy NevilleDNZ (talk) 04:18, 15 July 2011 (UTC)

syntaxhighlight tag changes by user:Boshomi[edit]

Yow. What is the point of replacing this:

int n = 2;
co n is a fixed constant of 2.co
int m := 3;
co m is a newly created local variable whose value is initially set to 3. 
    This is short for ref int m = loc int := 3; co
real avogadro = 6.0221415⏨23; co Avogadro's number co
long long real pi = 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510;
compl square root of minus one = 0 ⊥ 1

Which looks like Algol68 by this:

int n = 2;
co n is a fixed constant of 2.co
int m := 3;
co m is a newly created local variable whose value is initially set to 3. 
    This is short for ref int m = loc int := 3; co
real avogadro = 6.0221415⏨23; co Avogadro's number co
long long real pi = 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510;
compl square root of minus one = 0  1

Which looks like nothing on earth. HughesJohn (talk) 09:54, 28 September 2011 (UTC)

Well, it turns out that GeSHi can do a half-assed job if the source is UPPER stropped:

INT n = 2;
CO n is a fixed constant of 2.CO
INT m := 3;
CO m is a newly created local variable whose value is initially set to 3. 
    This is short for REF INT m = LOC INT := 3; CO
REAL avogadro = 6.0221415⏨23; CO Avogadro's number CO
LONG LONG REAL pi = 3.14159 26535 89793 23846 26433 83279 50288 41971 69399 37510;
COMPL square root of minus one = 0  1

But it's still not very pretty. (multi-line comments are not handled for example) HughesJohn (talk) 10:18, 28 September 2011 (UTC)

You are right! it's still not very pretty. The colours are ugly. I like blue colour for keywords and green vor comments.

So i will stop my work at this page. I think a reformating would be nice, when we get a better highlighting form the wikimedia project.

i have found the algol68.php file, used by mediawiki for source and syntaxhighlight tag: http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi This file should be replaced by a better one. This file is not too complicat:

folder: /Syntaxhighlight_GeSHi/geshi/geshi/ filename: algol68 --Boshomi (talk) 19:50, 28 September 2011 (UTC)

 <?php
/*************************************************************************************
 * algol68.php
 * --------
 * Author: Neville Dempsey (NevilleD.sourceforge@sgr-a.net)
 * Copyright: (c) 2010 Neville Dempsey (https://sourceforge.net/projects/algol68/files/)
 * Release Version: 1.0.8.10
 * Date Started: 2010/04/24
 *
 * ALGOL 68 language file for GeSHi.
 *
 * CHANGES
 * -------
 * 2010/04/24 (1.0.8.8.0)
 *   - First Release - machine generated by http://rosettacode.org/geshi/
 * 2010/05/24 (1.0.8.8.1)
 *   - #2324 - converted comment detection to RegEx
 * 2010/06/16 (1.0.8.8.2)
 *   - separate symbols from keywords - quick fix
 * 2010/06/16 (1.0.8.8.3)
 *   - reverse length order symbols
 *   - Add RegEx for BITS and REAL literals (INT to do)
 *   - recognise LONG and SHORT prefixes to literals
 * 2010/07/23 (1.0.8.8.4)
 *   - fix errors detected by langcheck.php, eg rm tab, fix indenting, rm duplicate keywords, fix symbols as keywords etc
 *   - removed bulk of local variables from name space.
 *   - unfolded arrays
 *
 * TODO (updated yyyy/mm/dd)
 * -------------------------
 *   - Use "Parser Control" to fix KEYWORD parsing, eg: (INT minus one= -1; print(ABSminus one))
 *   - Parse $FORMATS$ more fully - if possible.
 *   - Pull reserved words from the source of A68G and A68RS
 *   - Pull stdlib PROC/OP/MODE symbols from the soruce of A68G and A68RS
 *   - Pull PROC/OP/MODE extensions from the soruce of A68G and A68RS
 *   - Use RegEx to detect extended precision PROC names, eg 'long long sin' etc
 *   - Use RegEx to detect white space std PROC names, eg 'new line'
 *   - Use RegEx to detect white space ext PROC names, eg 'cgs speed of light'
 *   - Use RegEx to detect BOLD symbols, eg userdefined MODEs and OPs
 *   - Add REgEx for INT literals - Adding INT breaks formatting...
 *   - Adding PIPE as a key word breaks formatting of "|" symbols!!
 *
 *************************************************************************************
 *
 *     This file is part of GeSHi.
 *
 *   GeSHi is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   GeSHi is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with GeSHi; if not, write to the Free Software
 *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 *
 ************************************************************************************/
 
if(!function_exists('geshi_langfile_algol68_vars')) {
    function geshi_langfile_algol68_vars(){
        $pre='(?<![0-9a-z_\.])';
        $post='?(?![0-9a-z]|\.(?:[eE][+\-]?)?\d)';
        $post=""; # assuming the RegEx is greedy #

        $_="\s*";
 
        $srad="Rr";        $rrad="[".$srad."]";  # either one digit, OR opt-space in digits #
        $sbin="0-1";       $rbin="[".$sbin."]";  $_bin=$rbin."(?:[".$sbin."\s]*".$rbin."|)";
        $snib="0-3";       $rnib="[".$snib."]";  $_nib=$rnib."(?:[".$snib."\s]*".$rnib."|)";
        $soct="0-7";       $roct="[".$soct."]";  $_oct=$roct."(?:[".$soct."\s]*".$roct."|)";
        $sdec="0-9";       $rdec="[".$sdec."]";  $_dec=$rdec."(?:[".$sdec."\s]*".$rdec."|)";
        $shex="0-9A-Fa-f"; $rhex="[".$shex."]";  $_hex=$rhex."(?:[".$shex."\s]*".$rhex."|)";
 
        # Define BITS: #
        $prebits=$pre; $postbits=$post;
        $bl="2".$_.$rrad.$_.$_bin;
        $bl=$bl."|"."2".$_.$rrad.$_.$_bin;
        $bl=$bl."|"."4".$_.$rrad.$_.$_nib;
        $bl=$bl."|"."8".$_.$rrad.$_.$_oct;
        $bl=$bl."|"."1".$_."0".$_.$rrad.$_.$_dec;
        $bl=$bl."|"."1".$_."6".$_.$rrad.$_.$_hex;
 
        # Define INT: #
        $preint=$pre; $postint=$post;
        # for some reason ".0 e - 2" is not recognised, but ".0 e + 2" IS!
        # work around: remove spaces between sign and digits! Maybe because
        # of the Unary '-' Operator
        $sign_="(?:-|\-|[-]|[\-]|\+|)";  # attempts #

        $sign_="(?:-\s*|\+\s*|)"; # n.b. sign is followed by white space #

        $_int=$sign_.$_dec;
        $il=          $_int;                      # +_9           #

        $GESHI_NUMBER_INT_BASIC='(?:(?<![0-9a-z_\.%])|(?<=\.\.))(?<![\d\.]e[+\-])([1-9]\d*?|0)(?![0-9a-z]|\.(?:[eE][+\-]?)?\d)';
 
        # Define REAL: #
        $prereal=$pre; $postreal=$post;
        $sexp="Ee\\\\";   $_exp="(?:⏨|[".$sexp."])".$_.$_int;
        $_decimal="[.]".$_.$_dec;
 
        # Add permitted permutations of various parts #
        $rl=        $_int.$_.$_decimal.$_.$_exp; # +_9_._9_e_+_9 #
        $rl=$rl."|".$_int.$_."[.]".$_.$_exp;     # +_9_.___e_+_9 #
        $rl=$rl."|".$_int.$_.$_exp;              # +_9_____e_+_9 #
        $rl=$rl."|".$sign_.$_decimal.$_.$_exp;   # +___._9_e_+_9 #

        $rl=$rl."|".$_int.$_.$_decimal;          # +_9_._9       #
        $rl=$rl."|".$sign_.$_decimal;            # +___._9       #

        # The following line damaged formatting...
        #$rl=$rl."|".$_int;                       # +_9           #

        # Apparently Algol68 does not support '2.', c.f. Algol 68G
        #$rl=$rl."|".$_int.$_."[.]";             # +_9_.         #

        # Literal prefixes are overridden by KEYWORDS :-(
        $LONGS="(?:(?:(LONG\s+)*|(SHORT\s+))*|)";
 
        return array(
            "BITS" => $prebits.$LONGS."(?:".$bl.")".$postbits,
            "INT" => $preint.$LONGS."(?:".$il.")".$postint,
            "REAL" => $prereal.$LONGS."(?:".$rl.")".$postreal,
 
            "BOLD" => 'color: #b1b100; font-weight: bold;',
            "ITALIC" => 'color: #b1b100;', # procedures traditionally italic #
            "NONSTD" => 'color: #FF0000; font-weight: bold;', # RED #
            "COMMENT" => 'color: #666666; font-style: italic;'
        );
    }
}
$a68=geshi_langfile_algol68_vars();
 
$language_data = array(
    'LANG_NAME' => 'ALGOL 68',
    'COMMENT_SINGLE' => array(),
    'COMMENT_MULTI' => array(
        '¢' => '¢',
        '£' => '£',
        '#' => '#',
        ),
    'COMMENT_REGEXP' => array(
        1 => '/\bCO((?:MMENT)?)\b.*?\bCO\\1\b/i',
        2 => '/\bPR((?:AGMAT)?)\b.*?\bPR\\1\b/i',
        3 => '/\bQUOTE\b.*?\bQUOTE\b/i'
        ),
    'CASE_KEYWORDS' => GESHI_CAPS_NO_CHANGE,
    'QUOTEMARKS' => array('"'),
    'ESCAPE_CHAR' => '"',
    'NUMBERS' => GESHI_NUMBER_HEX_SUFFIX,  # Warning: Feature!! #
#                GESHI_NUMBER_HEX_SUFFIX, # Attempt ignore default #
    'KEYWORDS' => array(
# Extensions
        1 => array('KEEP', 'FINISH', 'USE', 'SYSPROCS', 'IOSTATE', 'USING', 'ENVIRON', 'PROGRAM', 'CONTEXT'),
#        2 => array('CASE', 'IN', 'OUSE', 'IN', 'OUT', 'ESAC', '(', '|', '|:', ')', 'FOR', 'FROM', 'TO', 'BY', 'WHILE', 'DO', 'OD', 'IF', 'THEN', 'ELIF', 'THEN', 'ELSE', 'FI', 'PAR', 'BEGIN', 'EXIT', 'END', 'GO', 'GOTO', 'FORALL', 'UPTO', 'DOWNTO', 'FOREACH', 'ASSERT'), #
        2 => array('CASE', 'IN', 'OUSE', /* 'IN',*/ 'OUT', 'ESAC', 'PAR', 'BEGIN', 'EXIT', 'END', 'GO TO', 'GOTO', 'FOR', 'FROM', 'TO', 'BY', 'WHILE', 'DO', 'OD', 'IF', 'THEN', 'ELIF', /* 'THEN',*/ 'ELSE', 'FI' ),
        3 => array('BITS', 'BOOL', 'BYTES', 'CHAR', 'COMPL', 'INT', 'REAL', 'SEMA', 'STRING', 'VOID'),
        4 => array('MODE', 'OP', 'PRIO', 'PROC', 'FLEX', 'HEAP', 'LOC', 'REF', 'LONG', 'SHORT', 'EITHER'),
# Extensions or deprecated keywords
# 'PIPE': keyword somehow interferes with the internal operation of GeSHi
        5 => array('FORALL', 'UPTO', 'DOWNTO', 'FOREACH', 'ASSERT', 'CTB', 'CT', 'CTAB', 'COMPLEX', 'VECTOR', 'SOUND' /*, 'PIPE'*/),
        6 => array('CHANNEL', 'FILE', 'FORMAT', 'STRUCT', 'UNION', 'OF'),
# '(', '|', '|:', ')',  #
#        7 => array('OF', 'AT', '@', 'IS', ':=:', 'ISNT', ':/=:', ':≠:', 'CTB', 'CT', '::', 'CTAB', '::=', 'TRUE', 'FALSE', 'EMPTY', 'NIL', '○', 'SKIP', '~'),
        7 => array('AT', 'IS', 'ISNT', 'TRUE', 'FALSE', 'EMPTY', 'NIL', 'SKIP'),
        8 => array('NOT', 'UP', 'DOWN', 'LWB', 'UPB', /* '-',*/ 'ABS', 'ARG', 'BIN', 'ENTIER', 'LENG', 'LEVEL', 'ODD', 'REPR', 'ROUND', 'SHORTEN', 'CONJ', 'SIGN'),
# OPERATORS ordered roughtly by PRIORITY #
#       9 => array('¬', '↑', '↓', '⌊', '⌈', '~', '⎩', '⎧'),
#        10 => array('+*', 'I', '+×', '⊥', '!', '⏨'),
        10 => array('I'),
#        11 => array('SHL', 'SHR', '**', 'UP', 'DOWN', 'LWB', 'UPB', '↑', '↓', '⌊', '⌈', '⎩', '⎧'),
        11 => array('SHL', 'SHR', /*'UP', 'DOWN', 'LWB', 'UPB'*/),
#        12 => array('*', '/', '%', 'OVER', '%*', 'MOD', 'ELEM', '×', '÷', '÷×', '÷*', '%×', '□', '÷:'),
        12 => array('OVER', 'MOD', 'ELEM'),
#        13 => array('-', '+'),
#        14 => array('<', 'LT', '<=', 'LE', '>=', 'GE', '>', 'GT', '≤', '≥'),
        14 => array('LT', 'LE', 'GE', 'GT'),
#        15 => array('=', 'EQ', '/=', 'NE', '≠', '~='),
        15 => array('EQ', 'NE'),
#        16 => array('&', 'AND', '∧', 'OR', '∨', '/\\', '\\/'),
        16 => array('AND', 'OR'),
        17 => array('MINUSAB', 'PLUSAB', 'TIMESAB', 'DIVAB', 'OVERAB', 'MODAB', 'PLUSTO'),
#        18 => array('-:=', '+:=', '*:=', '/:=', '%:=', '%*:=', '+=:', '×:=', '÷:=', '÷×:=', '÷*:=', '%×:=', '÷::=', 'MINUS', 'PLUS', 'DIV', 'MOD', 'PRUS'),
# Extensions or deprecated keywords
        18 => array('MINUS', 'PLUS', 'DIV', /* 'MOD',*/ 'PRUS', 'IS NOT'),
# Extensions or deprecated keywords
        19 => array('THEF', 'ANDF', 'ORF', 'ANDTH', 'OREL', 'ANDTHEN', 'ORELSE'),
# Built in procedures - from standard prelude #
        20 => array('int lengths', 'intlengths', 'int shorths', 'intshorths', 'max int', 'maxint', 'real lengths', 'reallengths', 'real shorths', 'realshorths', 'bits lengths', 'bitslengths', 'bits shorths', 'bitsshorths', 'bytes lengths', 'byteslengths', 'bytes shorths', 'bytesshorths', 'max abs char', 'maxabschar', 'int width', 'intwidth', 'long int width', 'longintwidth', 'long long int width', 'longlongintwidth', 'real width', 'realwidth', 'long real width', 'longrealwidth', 'long long real width', 'longlongrealwidth', 'exp width', 'expwidth', 'long exp width', 'longexpwidth', 'long long exp width', 'longlongexpwidth', 'bits width', 'bitswidth', 'long bits width', 'longbitswidth', 'long long bits width', 'longlongbitswidth', 'bytes width', 'byteswidth', 'long bytes width', 'longbyteswidth', 'max real', 'maxreal', 'small real', 'smallreal', 'long max int', 'longmaxint', 'long long max int', 'longlongmaxint', 'long max real', 'longmaxreal', 'long small real', 'longsmallreal', 'long long max real', 'longlongmaxreal', 'long long small real', 'longlongsmallreal', 'long max bits', 'longmaxbits', 'long long max bits', 'longlongmaxbits', 'null character', 'nullcharacter', 'blank', 'flip', 'flop', 'error char', 'errorchar', 'exp char', 'expchar', 'newline char', 'newlinechar', 'formfeed char', 'formfeedchar', 'tab char', 'tabchar'),
        21 => array('stand in channel', 'standinchannel', 'stand out channel', 'standoutchannel', 'stand back channel', 'standbackchannel', 'stand draw channel', 'standdrawchannel', 'stand error channel', 'standerrorchannel'),
        22 => array('put possible', 'putpossible', 'get possible', 'getpossible', 'bin possible', 'binpossible', 'set possible', 'setpossible', 'reset possible', 'resetpossible', 'reidf possible', 'reidfpossible', 'draw possible', 'drawpossible', 'compressible', 'on logical file end', 'onlogicalfileend', 'on physical file end', 'onphysicalfileend', 'on line end', 'onlineend', 'on page end', 'onpageend', 'on format end', 'onformatend', 'on value error', 'onvalueerror', 'on open error', 'onopenerror', 'on transput error', 'ontransputerror', 'on format error', 'onformaterror', 'open', 'establish', 'create', 'associate', 'close', 'lock', 'scratch', 'space', 'new line', 'newline', 'print', 'write f', 'writef', 'print f', 'printf', 'write bin', 'writebin', 'print bin', 'printbin', 'read f', 'readf', 'read bin', 'readbin', 'put f', 'putf', 'get f', 'getf', 'make term', 'maketerm', 'make device', 'makedevice', 'idf', 'term', 'read int', 'readint', 'read long int', 'readlongint', 'read long long int', 'readlonglongint', 'read real', 'readreal', 'read long real', 'readlongreal', 'read long long real', 'readlonglongreal', 'read complex', 'readcomplex', 'read long complex', 'readlongcomplex', 'read long long complex', 'readlonglongcomplex', 'read bool', 'readbool', 'read bits', 'readbits', 'read long bits', 'readlongbits', 'read long long bits', 'readlonglongbits', 'read char', 'readchar', 'read string', 'readstring', 'print int', 'printint', 'print long int', 'printlongint', 'print long long int', 'printlonglongint', 'print real', 'printreal', 'print long real', 'printlongreal', 'print long long real', 'printlonglongreal', 'print complex', 'printcomplex', 'print long complex', 'printlongcomplex', 'print long long complex', 'printlonglongcomplex', 'print bool', 'printbool', 'print bits', 'printbits', 'print long bits', 'printlongbits', 'print long long bits', 'printlonglongbits', 'print char', 'printchar', 'print string', 'printstring', 'whole', 'fixed', 'float'),
        23 => array('pi', 'long pi', 'longpi', 'long long pi', 'longlongpi'),
        24 => array('sqrt', 'curt', 'cbrt', 'exp', 'ln', 'log', 'sin', 'arc sin', 'arcsin', 'cos', 'arc cos', 'arccos', 'tan', 'arc tan', 'arctan', 'long sqrt', 'longsqrt', 'long curt', 'longcurt', 'long cbrt', 'longcbrt', 'long exp', 'longexp', 'long ln', 'longln', 'long log', 'longlog', 'long sin', 'longsin', 'long arc sin', 'longarcsin', 'long cos', 'longcos', 'long arc cos', 'longarccos', 'long tan', 'longtan', 'long arc tan', 'longarctan', 'long long sqrt', 'longlongsqrt', 'long long curt', 'longlongcurt', 'long long cbrt', 'longlongcbrt', 'long long exp', 'longlongexp', 'long long ln', 'longlongln', 'long long log', 'longlonglog', 'long long sin', 'longlongsin', 'long long arc sin', 'longlongarcsin', 'long long cos', 'longlongcos', 'long long arc cos', 'longlongarccos', 'long long tan', 'longlongtan', 'long long arc tan', 'longlongarctan'),
        25 => array('first random', 'firstrandom', 'next random', 'nextrandom', 'long next random', 'longnextrandom', 'long long next random', 'longlongnextrandom'),
        26 => array('real', 'bits pack', 'bitspack', 'long bits pack', 'longbitspack', 'long long bits pack', 'longlongbitspack', 'bytes pack', 'bytespack', 'long bytes pack', 'longbytespack', 'char in string', 'charinstring', 'last char in string', 'lastcharinstring', 'string in string', 'stringinstring'),
        27 => array('utc time', 'utctime', 'local time', 'localtime', 'argc', 'argv', 'get env', 'getenv', 'reset errno', 'reseterrno', 'errno', 'strerror'),
        28 => array('sinh', 'long sinh', 'longsinh', 'long long sinh', 'longlongsinh', 'arc sinh', 'arcsinh', 'long arc sinh', 'longarcsinh', 'long long arc sinh', 'longlongarcsinh', 'cosh', 'long cosh', 'longcosh', 'long long cosh', 'longlongcosh', 'arc cosh', 'arccosh', 'long arc cosh', 'longarccosh', 'long long arc cosh', 'longlongarccosh', 'tanh', 'long tanh', 'longtanh', 'long long tanh', 'longlongtanh', 'arc tanh', 'arctanh', 'long arc tanh', 'longarctanh', 'long long arc tanh', 'longlongarctanh', 'arc tan2', 'arctan2', 'long arc tan2', 'longarctan2', 'long long arc tan2', 'longlongarctan2'),
        29 => array('complex sqrt', 'complexsqrt', 'long complex sqrt', 'longcomplexsqrt', 'long long complex sqrt', 'longlongcomplexsqrt', 'complex exp', 'complexexp', 'long complex exp', 'longcomplexexp', 'long long complex exp', 'longlongcomplexexp', 'complex ln', 'complexln', 'long complex ln', 'longcomplexln', 'long long complex ln', 'longlongcomplexln', 'complex sin', 'complexsin', 'long complex sin', 'longcomplexsin', 'long long complex sin', 'longlongcomplexsin', 'complex arc sin', 'complexarcsin', 'long complex arc sin', 'longcomplexarcsin', 'long long complex arc sin', 'longlongcomplexarcsin', 'complex cos', 'complexcos', 'long complex cos', 'longcomplexcos', 'long long complex cos', 'longlongcomplexcos', 'complex arc cos', 'complexarccos', 'long complex arc cos', 'longcomplexarccos', 'long long complex arc cos', 'longlongcomplexarccos', 'complex tan', 'complextan', 'long complex tan', 'longcomplextan', 'long long complex tan', 'longlongcomplextan', 'complex arc tan', 'complexarctan', 'long complex arc tan', 'longcomplexarctan', 'long long complex arc tan', 'longlongcomplexarctan', 'complex sinh', 'complexsinh', 'complex arc sinh', 'complexarcsinh', 'complex cosh', 'complexcosh', 'complex arc cosh', 'complexarccosh', 'complex tanh', 'complextanh', 'complex arc tanh', 'complexarctanh')
        ),
    'SYMBOLS' => array(
        1 => array( /* reverse length sorted... */ '÷×:=', '%×:=', ':≠:', '÷*:=', '÷::=', '%*:=', ':/=:', '×:=', '÷:=', '÷×', '%:=', '%×', '*:=', '+:=', '+=:', '+×', '-:=', '/:=', '::=', ':=:', '÷*', '÷:', '↑', '↓', '∧', '∨', '≠', '≤', '≥', '⊥', '⌈', '⌊', '⎧', '⎩', /* '⏨', */ '□', '○', '%*', '**', '+*', '/=', '::', '/\\', '\\/', '<=', '>=', '|:', '~=', '¬', '×', '÷', '!', '%', '&', '(', ')', '*', '+', ',', '-', '/', ':', ';', '<', '=', '>', '?', '@', '[', ']', '^', '{', '|', '}', '~')
    ),
    'CASE_SENSITIVE' => array(
        GESHI_COMMENTS => false,
        1 => true,
        2 => true,
        3 => true,
        4 => true,
        5 => true,
        6 => true,
        7 => true,
        8 => true,
#        9 => true,
        10 => true,
        11 => true,
        12 => true,
#        13 => true,
        14 => true,
        15 => true,
        16 => true,
        17 => true,
        18 => true,
        19 => true,
        20 => true,
        21 => true,
        22 => true,
        23 => true,
        24 => true,
        25 => true,
        26 => true,
        27 => true,
        28 => true,
        29 => true
        ),
    'STYLES' => array(
        'KEYWORDS' => array(
            1 => $a68['NONSTD'], 2 => $a68['BOLD'], 3 => $a68['BOLD'], 4 => $a68['BOLD'],
            5 => $a68['NONSTD'], 6 => $a68['BOLD'], 7 => $a68['BOLD'], 8 => $a68['BOLD'],
            /* 9 => $a68['BOLD'],*/ 10 => $a68['BOLD'], 11 => $a68['BOLD'], 12 => $a68['BOLD'],
            /* 13 => $a68['BOLD'],*/ 14 => $a68['BOLD'], 15 => $a68['BOLD'], 16 => $a68['BOLD'], 17 => $a68['BOLD'],
            18 => $a68['NONSTD'], 19 => $a68['NONSTD'],
            20 => $a68['ITALIC'], 21 => $a68['ITALIC'], 22 => $a68['ITALIC'], 23 => $a68['ITALIC'],
            24 => $a68['ITALIC'], 25 => $a68['ITALIC'], 26 => $a68['ITALIC'], 27 => $a68['ITALIC'],
            28 => $a68['ITALIC'], 29 => $a68['ITALIC']
            ),
        'COMMENTS' => array(
            1 => $a68['COMMENT'], 2 => $a68['COMMENT'], 3 => $a68['COMMENT'], /* 4 => $a68['COMMENT'],
            5 => $a68['COMMENT'],*/ 'MULTI' => $a68['COMMENT']
            ),
        'ESCAPE_CHAR' => array(
            0 => 'color: #000099; font-weight: bold;'
            ),
        'BRACKETS' => array(
            0 => 'color: #009900;'
            ),
        'STRINGS' => array(
            0 => 'color: #0000ff;'
            ),
        'NUMBERS' => array(
            0 => 'color: #cc66cc;',
            ),
        'METHODS' => array(
            0 => 'color: #004000;',
            1 => 'color: #004000;'
            ),
        'SYMBOLS' => array(
            0 => 'color: #339933;',
            1 => 'color: #339933;'
            ),
        'REGEXPS' => array(
            0  => 'color: #cc66cc;',   # BITS #
            1  => 'color: #cc66cc;',   # REAL #
            /* 2  => 'color: #cc66cc;',   # INT # */
            ),
        'SCRIPT' => array()
        ),
    'URLS' => array(
        1 => '',
        2 => '',
        3 => '',
        4 => '',
        5 => '',
        6 => '',
        7 => '',
        8 => '',
#        9 => '',
        10 => '',
        11 => '',
        12 => '',
#        13 => '',
        14 => '',
        15 => '',
        16 => '',
        17 => '',
        18 => '',
        19 => '',
        20 => '',
        21 => '',
        22 => '',
        23 => '',
        24 => '',
        25 => '',
        26 => '',
        27 => '',
        28 => '',
        29 => ''
        ),
    'OOLANG' => true,
    'OBJECT_SPLITTERS' => array(
        0 => '→',
        1 => 'OF'
        ),
    'REGEXPS' => array(
        0 => $a68['BITS'],
        1 => $a68['REAL']
        # 2 => $a68['INT'], # Breaks formatting for some reason #
        # 2 => $GESHI_NUMBER_INT_BASIC # Also breaks formatting  #
    ),
    'STRICT_MODE_APPLIES' => GESHI_NEVER,
    'SCRIPT_DELIMITERS' => array(),
    'HIGHLIGHT_STRICT_BLOCK' => array()
);
 
unset($a68);
?>

Hi... I agree with the comments about highlight ugliness... I'll chat to BenBE about adding the common "stropping regimes". Maybe we can have:

  • <syntaxhighlight lang="algol68" src="point">
  • <syntaxhighlight lang="algol68" src="quote">
  • <syntaxhighlight lang="algol68" src="res">
  • <syntaxhighlight lang="algol68" src="upper">

or if "syntaxhighlight" cannot handle options (I'm not sure) I can try:

  • <syntaxhighlight lang="algol68_point">
  • <syntaxhighlight lang="algol68_quote">
  • <syntaxhighlight lang="algol68_res">
  • <syntaxhighlight lang="algol68_upper">

I'll see what BenBE recommends.

It seems that HTML/CSS has standard features that are Algol68 friendly, eg

  • the majority of Algol68's "special characters" (×, ÷, ≤, ≥, ≠, ¬, ⊃, ≡, ∨, ∧, →, ↓, ↑, ⌊, ⌈, ⎩, ⎧, ⊥, ⏨, ¢, ○ and □) are in the original 255 named HTML entities and
  • when Algol68 code is published it normally has "BOLD" words in <font style="font-weight: bold; text-transform: lowercase;">.

As far as the colors of the highlighted words goes... I'm thinking that php color scheme is close to what is asked for and I will retune Algol68's color to match.

Note that this could take a few months, because GeSHi's last release was 2011/02/11 (1.0.8.10), and there is probably a delay before Wikipedia pick new releases up.

Cheers NevilleDNZ (talk) 01:11, 7 October 2011 (UTC)

Merge proposal[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result was don't merge. -- HughesJohn (talk) 18:46, 8 December 2011 (UTC)

The articles ALGOL 68 and ALGOL 68S has been proposed for merger, without a motivation on this talk page. I therefore add my vote here:

  • oppose: write a motivation on the talk page if I'm going to vote! Adding merger proposals without a proper direct to a talk page topic is just sloppy templating. Rursus dixit. (mbork3!) 09:45, 25 October 2011 (UTC)
  • oppose: - ditto "write a motivation on the talk page if I'm going to vote!" Also: The Algol68 pages does not need to get bigger. Maybe we could have a consolidated List of ALGOL 68 implementations similar to Algol 68 implementations and dialects at the CHM . NevilleDNZ (talk)
  • I was going to write oppose, but I'm a bit conflicted. What is ALGOL 68S? The official sublanguage (which it seems should be discussed on the main ALGOL 68 page) or an implementation (or some implementations) of the official sublanguage (which might want their page or pages). Anyway, the merge proposal as formulated does seem incorrect "It has been suggested that ALGOL 68S be merged into this article or section." -- where? by who? By the way, I see the same drive-by merger proposal for ALGOL 68RS which I oppose: Either an expansion of the page (which I would like to get around to doing one day) or NevilleDNZ's implementation page seems a better idea. HughesJohn (talk) 10:29, 2 November 2011 (UTC)

So, when do we decide this dubious merge proposal is dead? HughesJohn (talk) 22:14, 6 December 2011 (UTC)

(Shouldn't have written dubious, sorry. HughesJohn (talk) 18:46, 8 December 2011 (UTC))

I've put in my rewritten ALGOL 68RS page, which I contend doesn't fit on the ALGOL 68 page. HughesJohn (talk) 19:41, 7 December 2011 (UTC)

Nice work on the ALGOL 68R & ALGOL 68RS. Educational. As the only other contributor that voted, it's been 2 months+, so I'd say now is a good time to remove the merge. You can do the honours. NevilleDNZ (talk) 03:50, 8 December 2011 (UTC)

As the consensus seems to be don't merge I'm removing the tags. It seems to me the best way forward is to try to improve the ALGOL 68S page. HughesJohn (talk) 18:46, 8 December 2011 (UTC)


The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.


case of name?[edit]

It seems there is a redirect from Algol_68 to ALGOL_68, so perhaps this has been discussed before. But the article does not seem quite consistent as to whether the name should be lower- or uppercase, although all-uppercase is used mostly, corresponding to the article link. However, the picture of the cover of the RR shows the name as Algol 68, which I find more "correct", or at least tasteful. Is there a policy for this in Wikipedia? I am aware that sources often use all-uppercase, so the inconsistency is perhaps "traditional", but that does not necessarily mean that this article can't be consistent, if it is desirable. --Lasse Hillerøe Petersen (talk) 19:52, 5 November 2012 (UTC)

Certainly 'Algol 68 is not so LOUD. The topic has been discussed before: Talk:ALGOL#Algol vs ALGOL (all-caps). 'Inside the report the name is consistently UPPERCASE, but the title page is Capital.

Here are two renditions of the report:

In the original on only place "Algol 68" appears is on the cover page. But in Algol68G's (more modern) reprint all ALGOL 60 and ALGOL68 have become Capitialised as Algol 6#.

Either way I am not so fussed. Let us revisit the issue in early 2014 and see if the are any specific objections added below. At that date - if no objections - we should rename the page to Algol 68 to match the report's cover title.

NevilleDNZ (talk) 12:33, 2 April 2013 (UTC)

From: "The Algollers" c. 1962 http://archive.computerhistory.org/resources/text/algol/ACM_Algol_bulletin/1061688/p8-de_morgan.pdf

I would suspect that from 1962 onwards ALGOL became Algol...

NevilleDNZ (talk) 14:41, 16 May 2013 (UTC)

Include ALGOL X as a section?[edit]

There is a page on ALGOL X, which is thin, and perhaps even incorrect. As I understand it, ALGOL X was the name used to refer to the "immediate successor" of Algol 60, while in the proposals phase, and not a specific and well-defined language for which any implementation existed. The language which eventually became ALGOL-W was one such proposal, and van Wijngaarden's language was another. The latter eventually evolved into Algol 68. I don't edit Wikipedia that much, and I don't know how to go about such a merge, which I assume it is. --Lasse Hillerøe Petersen (talk) 19:52, 5 November 2012 (UTC)

I kind of prefer each language to have it's own page, that way wiki links between language's pages can be direct. If push came to shove then a merge of all the "precursors" to Algol 68, maybe as some kind of list of ALGOL 60 dialects page.

ALGOL X was a bit unique in that it appears to have the precursors to classes;

Note: Ada (programming language) on wikipedia has retained its proposals as specific pages, i.e.:

I am thinking that ALGOL X could be merged with ALGOL W.

NevilleDNZ (talk) 12:51, 2 April 2013 (UTC)

Identifiers[edit]

Quote: blanks are ignored even within ALGOL 68 identifiers (effectively avoiding the underscores versus camel case versus all lower-case issues at once, but at the price of introducing a cornucopia of more serious problems in software engineering)

Firstly, this was already the case in Algol 60 (and FORTRAN!), so was nothing new. Secondly, unless someone can justify or explain "at the price of introducing a cornucopia of more serious problems in software engineering" I intend to remove that phrase. Pemboid (talk) 07:59, 14 June 2013 (UTC)

Seconded. Rp (talk) 22:41, 20 June 2013 (UTC)

The funarg problem[edit]

ALGOL 68 supports procedure arguments and return values of arbitrary type, so it would be worthwhile to discuss how it deals with the funarg problem. As far as I recall it really doesn't. Rp (talk) 11:04, 18 October 2013 (UTC)

While researching support of first-class functions in various languages, I vaguely remember finding the claim that ALGOL 68 supported returning functions, but that an actual implementation would throw a run-time exception if the function was no longer in scope at the point it was invoked. I've never seen an actual ALGOL 68 compiler, so I can't really confirm this, though. —Ruud 14:44, 19 October 2013 (UTC)
The informal introduction mentions the problem in the definition of event handling procedurers for I/O. A file structure contains pointers to procedures to be called on various error conditions. The problem was that it is pretty difficult to set the handlers for the standard input and standard output files because they had greater scope than user code:
bool badness happened = false;
proc handle badness (ref file f) bool :
begin
  badness happened = true;
  ... return true if problem fixed
end;
co scope of handle badness is same as scope of
   badness happened
co

on value error (standard input, handle badness); co scoping error! co

co the previous line is illegal as it does something like:
      value error of standard input := handle badness;
   and the scope of handle badness is smaller than the scope of standard input
co
In theory this problem should be detected by the compiler (the program isn't even syntacticaly correct - the Algol68 two-level grammar includes scoping information. In practice I'm not sure. HughesJohn (talk) 17:50, 5 November 2013 (UTC)