Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!emory!mephisto!udel!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.society.futures
Subject: Re: C's sins of commission (was: (pssst...fortran?))
Message-ID: <64898@lanl.gov>
Date: 4 Oct 90 20:15:31 GMT
References: <5088@uqcspe.cs.uq.oz.au>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 73

From article <5088@uqcspe.cs.uq.oz.au>, by brendan@batserver.cs.uq.oz.au (Brendan Mahony):
> [...]
> It seems to me that this attitude could reasonably be likened to the
> antiquated European belief that regular bathing was dangerous to the
> health. Indeed we now believe that bathing is good for the health
> provided the water supply is clean and hygenic. [...]

A very good analogy, and one which is also directly applicable to the
issue of pointers in languages.

> [...]                                           The percieved need for
> side-effects in terms is merely a by-product of the poor state of language
> design, and would not be missed at all in better languages.

This, however, is not clear.  Mathematical notation for random variates
existed before computing languages.  The variates were always of the same
form as ordinary variables.  In fact, that is what I think the use of
random generators should look like.  What you are suggesting is that
the programmer should alter his notation to suit the language, not
the other way around.  I think that it is the language that should
cater to the desires of the programmer.

> [...]
> The purpose of terms is to define values. In serving this purpose they
> need above all to be UNAMBIGUOUS. Terms with side effects are ambiguous.

No, they aren't ambiguous (necessarily).  As long as the order of
evaluation of such terms are predictable and the nature of the side-
effect of each is known, their use is completely unambiguous.  Now,
in languages like C (where the order of evaluation is not specified
and the nature of the side-effects needn't be declared), the feature
is indeed quite ambiguous.

If all side-effects that a function might cause are clearly defined
in the function interface, the compiler can then generate code so that
the side-effects are evaluated in a fixed order with respect to other
functions (or local assignments) which have side-effects on the same
objects.  This is a completely unambiguous solution - and functions
that _don't_ have side-effects can still be optimized fully.

> [...]
> Actually to do this you will need to specify the local/global state
> being side effected by the function. Since this is required why not
> "officially" include it in the interface?

Indeed.  The interface should contain a complete list of global variables
that it modifies, the specific arguments that it modifies should be
identified, and the function declaration should specify if it has any
internal, time-dependent, state.

> [...]
>>(and, at least with regard to random number generators, I tend to agree).
> 
> I have discussed random number generators elsewhere, but I do not see
> how using a procedure instead of a function is such a burden that we
> must admit ambiguous terms.

One of the problems with language design is that most designers are not
in daily touch with their potential user base.  How much of a burden
the prohibition of side-effects in functions would pose is not for
the language designer to say.  I know mathematical/scientific users
who would deem it a considerable burden indeed.

Note: the requirement of explicit declarations of all side-effects,
especially if backed up by the loader which can check that such
assertions are true, would actually decrease the use of side-effects
on its own.  After all, who would go to such trouble unless it was
outweighed by the trouble of avoiding it?  This indeed, would be
a good empirical test of your claim that side-effect free functions
aren't a burden - how much trouble are the users willing to go to
in order to still have them?

J. Giles