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