Hacker News Reader

Comment by T-R | Hacker News Reader

That still means the function can't be treated as referentially transparent (whereas a Haskell function with debug output still can be, for the most part).

Don't get me wrong, that's still somewhat useful - it tells me "this function doesn't do anything too crazy", but it doesn't tell me "it should be safe to refactor this without having to read the function bodies of the entire call graph below this point", which makes calling it "pure" seem a bit disingenuous.

View on HN

Given pure + @safe + immutable arguments, how is it not referentially transparent? (we ignore the practical concessions: debug statements, memory management, termination, floating point hardware state)

I'm not saying it isn't - it's certainly good that it's also possible to declare something as referentially transparent, but defining the keyword "pure" to imply something much less than referential transparency is still a poor choice.

Edit: To be clear, I don't really feel too strongly about it. It's still leagues ahead of many other languages - I just think that particular choice of keyword is likely to confuse things a bit.

In D, if a function is pure, can it call a function that modifies global state?

That is to say (in not necessarily real D, just close enough) given:

   int global_var

   void modify_global(int z) {
      global_var += z;
      return global_var;
   }
   pure int foo(int x) {
      return x + modify_global(2);
   }

What happens? Does the compiler barf because it causes modification to something not passed? If so, assuming that you can only modify the object passed (via methods of it, and presumably, the things that object points to in its members),

then it maintains something much closer to referential transparency than you are implying.

The compiler says:

    /d111/f857.d(9): Error: pure function 'f857.foo' cannot call impure function 'f857.modify_global'

> In D, if a function is pure, can it call a function that modifies global state?

Nope (it would be a useless feature if it could).

But that's a pretty low bar. Using just 'pure', can you mutate an argument in a function called in a conditional expression (making it unsafe to check again)? Can it matter what order a list gets processed in a call to `map` or `filter`? Preventing mutation of global variables narrows the scope of the damage, but having just that still means that if you're maintaining someone else's code, you need to double check everything for side effects, even if they'd be limited to the inputs.

Declare the parameter as 'const' and you know the pure function cannot mutate it. Declare it as 'immutable' and you know that nobody else can mutate it, either.

Reply on news.ycombinator.com