Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!bowles
From: bowles@eris.berkeley.edu (Jeff A. Bowles)
Newsgroups: comp.lang.c
Subject: Re: C optimizer
Keywords: C pure function optimization
Message-ID: <20368@agate.BERKELEY.EDU>
Date: 14 Feb 89 16:48:06 GMT
References: <515@larry.UUCP> <9648@smoke.BRL.MIL> <13134@steinmetz.ge.com>
Sender: usenet@agate.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 26

In article <13134@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>  I agree. One solution would be to provide a keyword, perhaps something
>like 'pure' or 'deterministic', which would indicate that a procedure
>always returns the same value for a set of given arguments. Note that
>this is not the same thing a "no side effects," my intent is only that a
>second call with the same arguments would not change the side effects
>(such as saving one of the arguments, etc).

One language I read about in ages past had the notion of function versus
procedure as defined below:
	function: Like a mathematical function, is strictly a function of
		  its arguments. (Perhaps the arguments might be put through
		  a "known" transformation, like a table lookup, but this
		  idea tends to support the notion that a set of inputs gives
		  the same output, consistently.)
	subroutine: fair game.

Now, in C, it's harder than you think - because if you pass a pointer to
a procedure, it's difficult to keep the procedure from modifying data to
which the argument points. Notions like "const" and function prototypes
make it a little easier to decide what a procedure DOESN'T do, but it's
pretty hard to tell if a procedure will fit the definition of a "function"
above.

	Jeff Bowles
case