Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!seal.cis.ohio-state.edu!ogden
From: ogden@seal.cis.ohio-state.edu (William F Ogden)
Newsgroups: comp.lang.eiffel
Subject: Re: Reference Semantics
Message-ID: <135300@tut.cis.ohio-state.edu>
Date: 17 Jun 91 18:02:51 GMT
References: <1181@tetrauk.UUCP> <133169@tut.cis.ohio-state.edu> <6351@goanna.cs.rmit.oz.au>
Sender: news@tut.cis.ohio-state.edu
Organization: The Ohio State University, Department of Computer and Information Science
Lines: 43

In article <6351@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) 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.  ...

>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.

(I assume this isn't a call for reviving the GoTo :-) Procedures which
have explicit parameters and don't side-effect global variables are
semantically simpler than GoTo's and Labels. Side-effecting procedures
probably don't offer much advantage over GoTo's.

Now the fact that a compiler hides the low-level jump statement and only
uses it in safe ways is precisely the point of a good high-level abstraction.
The user of higher level control constructs really lives in a semantically
simpler and safer world.

>    ...                                             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'.

I certainly agree that sharing should be explicitly indicated; the above 
remarks were part of a discussion about the dangers of the routine unflaged
sharing which is implicit in reference semantics. However, I believe you've
drawn a false dichotomy between languages with sharing and pure functional
languages. There's not much sharing in a language like say FORTRAN or BASIC,
but I really doubt the functional language camp would claim such languages
either.

--

/Bill