Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!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: <6375@goanna.cs.rmit.oz.au>
Date: 18 Jun 91 05:55:31 GMT
References: <1181@tetrauk.UUCP> <133169@tut.cis.ohio-state.edu> <135300@tut.cis.ohio-state.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 84

In article <135300@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes:
> In article <6351@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >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 :-)

I don't see why you're assuming anything.  Read my lips:  Goto is not dead.
> Procedures which
> have explicit parameters and don't side-effect global variables are
> semantically simpler than GoTo's and Labels.

I'm sorry, but this turns out not to be the case.  Let me repeat the
sentence above:
	ANY semantic problems that were ever associated with gotos
	[insertion:  gotos in fact have *very* simple proof rules]
	remain in FULL force when you use procedure calls
	[insertion: in fact proof rules for procedure calls are
	MORE complex than proof rules for labels and gotos.]
This is not a theoretical abstraction.  I have noticed, IN PRACTICE,
that when reading a couple of hundred lines of functional code (which
I like, make no mistake) I get the same sensation as when I used to
read assembly code.  There is one great big mass of spaghetti, and
unsnarling references to functions (when every second line defines
a new function) is not one iota easier than unsnarling references to
labels.

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

You have missed the point completely.  The point is that the difficulty
with gotos was not that they were theoretically unclean (quite the
opposite!  I repeat, the proof rules for (local) goto are SIMPLER than
the proof rules for procedure call) but that you had to do a lot of
moving your finger around a listing and mumbling to yourself to figure
out what came from where.  The hardware jump was never the problem, it
was figuring out what the connection between a particular jump and a
particular label MEANT.  As soon as you have thousands of little
procedures, you get exactly the same kind of problems grasping the
interconnections.

> The user of higher level control constructs really lives in a semantically
> simpler and safer world.

This turns out not to be the case.  *Anything* you could do with labels
can be done IN THE SAME WAY (I mean preserving apparent structure, size of
output of transliteration process is a linear function of size of input)
using function calls.  This has been known since the early 60s, where have
you been?

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

There is a h**l of a lot of sharing in Fortran.  It's the major factor
inhibiting the parallelisation that the scientific computing people would
like to get.  Where is the sharing?  Destructive assignment to array
elements.  Think
	pointer : set of objects of base type :: integer : array
There was an experiment reported about 4 or 5 years ago in one of the
parallel programming conferences which studied this very matter.
The best parallel speedups on the codes studied were around 15; when
the synchornisation bottleneck due to this sharing was eliminated the
speedups were as much as 700.  

I basically made the same point twice, and it was completely missed twice.

    Just because it doesn't LOOK like a goto doesn't mean that it doesn't
    ACT like a goto and have the PROBLEMS of a goto.
    Just because it doesn't LOOK like a pointer doesn't mean that it
    doesn't ACT like a pointer and have the PROBLEMS of a pointer.

As for whether the functional community would claim Fortran or Basic,
they *were* credited with Euclid (very Pascalish, but no aliasing).
And the Boyer-Moore theorem prover was used to verify some Fortran
examples by transliterating them into pure Lisp...


To get back to OOP:  the problem is not sharing, but _assignment.
Objects belonging to a class that cannot be modified could be shared
without anyone noticing.
-- 
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.