Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.eiffel
Subject: Re: Reference Semantics
Message-ID: <6351@goanna.cs.rmit.oz.au>
Date: 15 Jun 91 06:14:32 GMT
References: <131691@tut.cis.ohio-state.edu> <1181@tetrauk.UUCP> <133169@tut.cis.ohio-state.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 33

In article <133169@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
> In article <1991Jun10.215822.28034@m.cs.uiuc.edu> johnson@cs.uiuc.EDU (Ralph Johnson) writes:
>    ...
> >Improper use of references can certainly cause problems, but
> >improper use of anything can cause problems. 

> Improper use of GoTo's can certainly cause problems also, but we don't
> use them much any more. We observed that there was a problem and that
> there were efficient alternatives, and we changed our ways.

I suggest that this is a bogus argument.  I often use functional languages
that haven't even got assignment, let alone something with 'goto' syntax.
But they _do_ exploit ``tail call optimisation'', so it is just as
accurate to look at a network of function definitions and say "those are
labels, those calls are gotos".  That's what they compile into, after all.
Any semantic problems that were ever associated with gotos remain in full
force when you use procedure calls.

There are two kinds of problems with pointers:  allocation status mistakes
and unexpected consequences of sharing.  Allocation status mistakes we can
easily get rid of:  if you write programs in CLOS or SCOOPS or Smalltalk
or ... then you simply can't express the mistakes.  There are good
arguments for saying that sharing ought to be explicitly marked, so that
structured values which weren't intended to be shared don't have unexpected
consequences, but if sharing isn't allowed at all, then your language is a
pure functional language in all but syntax and has no `objects'.  When you
are modelling a situation in which an entity can change state, and you
want more than one other entity to be able to refer to the changing
entity, you have all the problems of sharing whether you use pointers,
references, object IDs, indexes into an array, or artificial telepathy.
-- 
Q:  What should I know about quicksort?   A:  That it is *slow*.
Q:  When should I use it?  A:  When you have only 256 words of main storage.