Purity

[Michel Fortin]

On 2010-12-18 07:46:11 -0500, Don <nospam at nospam.com> said:

> spir wrote:
>> On Sat, 18 Dec 2010 01:08:20 -0800
>> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> 
>> Thank you for the explanation about strongly pure funcs calling weakly 
>> pure ones --this fully makes sense.
>> 
>>>> I would like weakly pure to include output funcs, and exclude all
>>>> possibilities to modify (non-local) state.
>>> The problem is that output is accessing global variables - which weakly 
>>> pure functions _cannot_ do.
>> 
>> Why? What is the rationale for excluding output (I don't mean I/O, only O)?
> 
> You're correct in saying that it doesn't affect the operation of the 
> program. But in practice, program output is almost always important.
> 
> For example, suppose we allowed output to be pure. Then consider:
> 
> writeln("Hello, world!");
> 
> Since it returns nothing, and has no influence on the future execution 
> of the program, the writeln can be dropped from the program.

I agree with that for writeln, the function at global scope, can't be 
pure. The reason is simple: it refers to the stdout global variable.

However, if someone was to pass stdout as a non-const function 
parameter I think it should work:

	pure void fun(File output, string msg) {
		output.writeln(msg);
	}

	void main() {
		fun(stdout, msg);
	}

File.writeln cannot be strongly pure since it gets the File as a 
reference (and so it can't be optimized away), but it can be weakly 
pure. One could argue that this is not terribly useful since no 
strongly pure functions will be able to do IO, but there might be other 
reasons one would want a weakly pure function other than enabling 
strongly pure ones. (For one instance of this, see my two posts in the 
other discussion "Threads and static initialization".)

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/