You're thinking of Pascal. In Algol 60 labels could certaainly be integers, but
didn't have to be. Instead of designing Pascal to make GOTO less necessary,
Wirth just made it more dangerous )-:
Shmuel (Seymour J.) Metz
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@listserv.uga.edu> on behalf
of Paul Gilmartin <00000014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Tuesday, February 13, 2018 1:55 PM
Subject: Re: Call by name
On 2018-02-13, at 10:09:30, Seymour J Metz wrote:
> Something just occurred to me with regard to call by name. There are no SETS
> and USES attributes in an Algol 60 parameter declaration. If a parameter is
> used as an l-value, there is a potential problem. A value like A[I} is
> legitimate on either side of an assignment, but a value like A[I]+1 is valid
> only on the right.
Given the definition of call by name as effectively copying the actual
parameter over the formal parameter then copying the modified subroutine
over the call statement, this is something the compiler should easily
I suspect the designers gave little thought to separately compiled
subroutines -- likewise that's not in Wirth's specification of Pascal.
Algol 60 statement labels are integers. The calling code must be
prepared for the subroutine's using "42" as a number, a label, or both.
Likewise types -- identfiers appearing in actual parameters are defined
in the scope of the caller. The same formal parameter might be associated
with an int in one call and a real in another, if syntactically acceptable
to the subroutine,
Call by name has fallen out of vogue. And C doesn't support nested
> In languages with call by reference and with procedure parameters, this
> becomes a non-issue: A[I]+1 is not a valid reference.