7 ms·

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

by T-R 12y ago

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.

qznc 12y ago
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)
- T-R 12y ago
  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.
  - sophacles 12y ago
    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.
    - nbm 12y ago
      The compiler says: /d111/f857.d(9): Error: pure function 'f857.foo' cannot call impure function 'f857.modify_global'
    - T-R 12y ago
      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.
      - WalterBright 12y ago
        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.
    - WalterBright 12y ago
      > 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).

by T-R 12y ago

qznc 12y ago

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)

T-R 12y ago
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.
- sophacles 12y ago
  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.
  - nbm 12y ago
    The compiler says: /d111/f857.d(9): Error: pure function 'f857.foo' cannot call impure function 'f857.modify_global'
  - T-R 12y ago
    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.
    - WalterBright 12y ago
      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.
  - WalterBright 12y ago
    > 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).