Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: C optimizer
Message-ID: <1484@mcgill-vision.UUCP>
Date: 29 Mar 89 11:07:05 GMT
References: <36662@think.UUCP> <453@lakart.UUCP> <1470@mcgill-vision.UUCP> <21652@agate.BERKELEY.EDU>
Organization: McGill University, Montreal
Lines: 44

In article <21652@agate.BERKELEY.EDU>, bowles@eris.berkeley.edu (Jeff A. Bowles) writes:
[many attribution lines seem to have been lost -dM]
>>>>> (getpid() != getpid())  [should always be 1]
>>>> [how about] (pid = getpid(), (void) fork(), pid != getpid())
>>> What he is stating is that _IN THE ABSENCE_ of fork() calls,
>>> getpid() had better return an unchanging value.
[this next comment was mine -dM]
>> Sure - and in the absence of assignments, variables are constant and
>> can be optimized away.  [... A] routine isn't pure if calling
>> another routine can cause it to change its return value for a given
>> set of argument values.

> Are we still on this topic? By the bogosity above, nothing is "pure",
> because you might write a function that changes the behaviour of
> another function - [...example with ftell...]

ftell() is of course not pure, as you noted, because there are
functions (fread, fseek, fwrite, fclose, etc) that can cause its return
value to change.

sin(), on the other hand, is: if I call sin() with some argument value,
and then call it again with the same value, the second call *will*
return the same value, regardless of what other routines I've called in
the meantime.  This is what I mean (and understand to be meant) by a
"pure" function.

> 1. These functions are pure, i.e. the values returned will not change
>    from one invocation to the next, given that the arguments didn't
>    change:

...and provided that certain other things don't happen between the two
invocations, generally calling certain other functions with certain
arguments, the set of forbidden functions and arguments varying with
the function being considered.

This is a much weaker property, but one which may still be useful in
some circumstances.  Which one should properly be called "pure" is a
different argument entirely (and one which I won't argue here except to
note that I'll stick with the stronger meaning).

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu