Talk:ALGOL 68C

Peter Craven's ALGOL 68 (Algol Applications Ltd)

It looks like a different parser/compiler and hence entry was in error.

• c.f. Talk:ALGOL_68#Peter Craven of Algol Applications Ltd and A68C.

Source: http://hopl.murdoch.edu.au/showlanguage2.prx?exp=667

NevilleDNZ 07:57, 6 March 2007 (UTC)

The "first" Algol68C compiler?

c.f. Algol68-user Question re: Cambridge Algol68C and Zcode?

What was the _first_ Algol68C compiler written in?  
Does anyone have a Zcode manual?  Or know where I can find one online?

NevilleDNZ (talk)

Algol 68C on the Harris 135, 500 and 800

Dr David Masters of Hull University and later American University of Paris ported Algol68C to the Harris 135 and 500 computers, aided by Rob Miles and John Hughes.

The Zcode->Harris assembler used parts of the backend of the Pascal compiler he ported from the ICL 1900 to the Harris. HughesJohn (talk) 13:22, 1 April 2011 (UTC)

ALGOL 68C extensions: bounds in formal-declarers

This is most bizarre. ALGOL 68 (revised) dropped bounds in formal declarers in imitation of ALGOL 68R. And ALGOL 68C went and put them back. Can't these people make their minds up! HughesJohn (talk)

I used both ALGOL 68C and ALGOL 68G, both as r1, neither with either. Am I right in saying that either in r0 means that the array can be either flex or fixed in length?

NevilleDNZ (talk) 23:49, 30 May 2011 (UTC)

Yup, that's what it seems to mean - see Lindsey's quote "I think it was a reasonable thing myself to omit the bounds from the formal-declarers but I think it was a terrible crime to omit the either or the flex" about ALGOL 68R. HughesJohn (talk) 16:06, 31 May 2011 (UTC)

ENVIRON: ?

I fail to understand the explanation of the ENVIRON / USING mechanism given here. It would be better to give a fully self-contained example.

As far as I can recall and reconstruct from the given example and my own A68C files, the mechanism works as follows:

• Every source code file is compiled separately.
• Within the source code, a statement ENVIRON followed by an identifier is a reference to a code unit with the given name. That code may not yet exist - it is not consulted at compile time.
• Within the source code, a statement USING followed by an identifier, FROM, and another identifier, indicates that the code which follows will compile into a code unit with the first name for inclusion by a code unit with the second name. That latter unit must already exist in compiled form. (Is this true?)

An attempt to improve the given example:

Suppose the file MAIN.A68 contains:

BEGIN
   INT dim = 3; # a constant #
   INT a number := 120; # a variable #
   MODE MATRIX = [dim, dim]REAL; # a type definition #
   ENVIRON FOO;
   a number := ENVIRON BAR;
   print ((a number))
END

while the file EX1.A68 contains:

USING FOO FROM "main"

MATRIX m1;

and the file EX2.A68 contains:

USING BAR FROM "main"

BEGIN
  MATRIX m2 = m1;
  print ((a number));
  2 UPB m2
END

Semantically, the effect of this is to replace the statement ENVIRON FOO in MAIN.A68 by the code given in EX1.A68, and the statement ENVIRON BAR by the code given in EX2.A68.

However, the mechanism by which this is achieved is different from how things work in e.g. C, C# or Java.

• MAIN.A68 can be compiled by itself, without consulting any other source code or compiled code.
• EX1.A68 can only be compiled after MAIN.A68 has been successfully compiled, as it will not be able to resolve its use of MATRIX otherwise.
• EX2.A68 can only be compiled after both MAIN.A68 and EX1.A68 have been successfully compiled, as it will not be able to resolve its use of MATRIX, a number and m1 otherwise.
• The code in MAIN.A68 cannot use the identifier m1. In principle, such references are valid, but not in this case, as it would create a cyclic order dependency: EX1.A68 would need to be compiled before MAIN.A68, while the opposite is also true. (Can anybody confirm or refute this?)

The compiled units are only linked together at run time.

So while ENVIRON is very similar to C's #include it its effect, it works completely differently: #include literally includes the source code of another file at compile time, while ENVIRON is only resolved at link time, against compiled code, not source code. USING is actually quite similar to Java's import statement and C#'s using statement, except that, as the article already states, USING is intended to be applied in the opposite direction, due to the pairing with ENVIRON, for which C# of Java have no equivalent.

Is this a correct description? Who can clarify? I have no access to a working A68C compiler, as far as I know. Rp (talk) 20:07, 31 July 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on ALGOL 68C. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050724183114/http://hopl.murdoch.edu.au/showlanguage.prx?exp=667 to http://hopl.murdoch.edu.au/showlanguage.prx?exp=667

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:12, 1 October 2016 (UTC)