Purity

spir denis.spir at gmail.com
Sat Dec 18 06:31:42 PST 2010


On Sat, 18 Dec 2010 12:30:31 +0100
"Simen kjaeraas" <simen.kjaras at gmail.com> wrote:

> spir <denis.spir at gmail.com> wrote:
> 
> > -1- How can this even compile?
> > 	pure append (ref int[] a, int i) {a ~= i;}
> > The _only_ task of this func is to change state.
> 
> It is designed to be usable in strongly pure functions. A strongly pure
> function may call this weakly pure function without compromising its
> purity. This because the strongly pure function could only pass the
> weakly pure function its own local state, and changes would thus be
> limited to the strongly pure function's scope.

Right, thank you.

> > -2- Why is output writing considered an impure task? It has no influence  
> > on the rest/future of the program, lets reasoning easy, does not touch  
> > state.
> 
> Output would be affected by pure optimizations:
> 
> pure int writeStuff() {
>      output( "Hi!" );
>      return 1;
> }
> 
> void foo( ) {
>      int a = writeStuff( ) + writeStuff( );
> }
> 
> Normally, the compiler could rewrite to
>      int a = 2 * writeStuff( );
> but that would fuck up output.

... which means the optimisation scheme is wrong for "action-funcs".

Note: As said in // post, languages maybe should properly make a distinction between action-functions & true functions (returning a result) --but I'm aware this goes against the whole culture of the C-line languages.
I consider funcs like this one, that both perform an effect and return a result, as confusing, and even erroneous, design/style.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com



More information about the Digitalmars-d mailing list