Anthony Stone writes:

 >       n=n+1; GOTO segment(list(n))
 > I don't think that this is at all inscrutable.

It may not be inscutable, but neither is it legal.  And I wouldn't
count on it working.  ASSIGN had quite a few quirks - it was not as
simple a thing to deal with as you might think on the surface.

Imagine systems where an address doesn't fit in the size of a
default integer.  That's one of those situations that might once
have been met with comments like "lets stick to realistic
systems".  But such systems are now quite common and becomming
more so.

Imagine compilers handling this by actually having two separate
storage areas for any integer variable used in an ASSIGN.  One area
for when the variable is used as a numeric integer, and another,
differently sized, area for when the variable is used as an ASSIGN'ed
label.  This happens in real compilers.  Its implications are a mess.

The f77 standard says that the ONLY thing that you can ASSIGN to
is a "variable name".  That specifically does not include an
array element.  Considering the business that some compilers need
to do with keeping track of the "shadow variable" (the extra
storage location that's a different size from default integers),
I wouldn't count on the array case being accepted as an extension.
I've never tried it (rarely used ASSIGN, even the legal forms,
and certainly not at all in the last 20 years or so) , so I don't
know for sure, but I wouldn't count on it.

A CASE statement would be the most likely replacement, but I'm not
prepared to go into details of specifics at the moment.  Note that
CASE is designed to be efficiently implementable (as something like a
table lookup instead of a sequential search).

Oh yes, rereading your post, I see a bunch of other things that are
likely problematic with it in terms of ASSIGN.  As I mentioned
earlier, ASSIGN is really quirky.  You can't pass variables that
have been assigned to from one subroutine to another and expect
anything to work.  (The compiler wouldn't know that you really wanted
to pass the "shadow variable" instead of the numeric one).  You
can't even do

  assign 1000 to i
  j = i

Talking about the reasons for committee decisions is always a risky
business.  But I'd venture the guess that the obsolescence of ASSIGN
had more to do with its quirks than with notions of "structured
programming" (although the later might have well also been an
influence).  ASSIGN as defined in f77 is really quite a "hack".
It requires a lot of trickery to make work at all (things like the
shadow variable stuff), and it has very non-intuitive consequences.
I'd personally think that if one wanted to design something that
worked as much like it as reasonable, but got rid of the quirks,
you'd want a separate data type for the ASSIGNED variables instead
of just using integers.  Its the overloading of the use of INTEGER
that causes the really ugly quirks.  Not that I think such a data
type would "sell" at the moment...and not that I'd probably be in
favor of it myself...but that I think is the most problematic issue
with ASSIGN.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%