Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!olivea!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!syacus!ian
From: ian@syacus.acus.oz.au (Ian Joyner)
Newsgroups: comp.lang.eiffel
Subject: Re: Reference Semantics
Message-ID: <1991Jun20.003529.27557@syacus.acus.oz.au>
Date: 20 Jun 91 00:35:29 GMT
References: <1991Jun10.215822.28034@m.cs.uiuc.edu> <133169@tut.cis.ohio-state.edu> <1991Jun11.223305.16439@m.cs.uiuc.edu> <133611@tut.cis.ohio-state.edu>
Organization: ACUS Australian Centre for Unisys Software, Sydney
Lines: 43

ogden@seal.cis.ohio-state.edu (William F Ogden) writes:

>C pointers are surely a more `interesting' mechanism, perhaps engendering
>a level of excitement in programming more comparable to that produced by
>the jump instruction in assembly languages. Be that as it may, it still
>seems that an object which is the target of multiple references is completely
>analogous to a label which is the target of multiple GoTo's.

Bill, I agree with most of what you are saying, but I don't think this
is the reason for considering gotos harmful. If it were then we would
also ban routines being called from multiple places.

There does seem to be some confusion about the banning of gotos in the
general discussion. Banning gotos does not mean that the only form
of flow of control allowed is sequential execution. Branches in logic
are permitted, its just that they must be accomplished by the well
disciplined means of conditional branches, loops and routine call/return
mechanisms, (and debatably case.) These mechanisms are sufficient for
all control requirements, and therefore gotos are unnecessary. The
remaining place where gotos make code neater may be provided by
supplying an error handling exit mechanism, other than return.
However, all these mechanisms may also be simulated by the use of
gotos.

Perhaps in this reference question, we should not look for solutions
first, but address the fundamental problem, if we can decide what
that is.

I think the fundamental problem is is it necessary to 
have multiple accesses to one common piece of data?

If the answer is yes, then we need to determine the best means
of fulfilling that requirement.

--
Ian Joyner
Australian Centre for Unisys Software
61-2-390 1328
ian@syacus.oz
-- 
Ian Joyner                                     ACSNet: ian@syacus.oz
ACUS (Australian Centre for Unisys Software)   DNS:  ian@syacus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz