
Function Purity and Immutability in D - andrewbinstock
http://www.drdobbs.com/architecture-and-design/function-purity-and-immutable-data-struc/240169087
======
wyager
>A pure function does not read or write any mutable data that is not
accessible via the function's arguments [but it can read/write mutable data
pointed to by its arguments]

That's not a particularly strong or interesting definition of purity. It just
means you can't have mutable globals. That is not really powerful or helpful
in any way that I can see.

I feel like this is a bit of a disingenuous (or perhaps just misunderstanding)
attempt to latch onto a buzzword from the functional programming realm that
means something almost completely different. Purity has a much stronger
definition than "don't mutate global variables". See
[http://en.wikipedia.org/wiki/Pure_function](http://en.wikipedia.org/wiki/Pure_function)

~~~
qznc
A function simply annotated with pure is sometimes called "weakly pure". If
its arguments are declared immutable, it is "strongly pure" which essentially
matches your definition.

All languages I know (e.g. Haskell) make concessions to pragmatism. For
example, even pure function can somehow create debug output. Every memory
allocation does mutate global state.

The weakly pure class of functions is useful. It limits the potential side-
effects to stuff reachable from mutable arguments. For example, a image filter
function can be weakly pure while it mutates the image provided as an
argument. It removes the need allocate a return image or wrap computations in
monads and thunks.

To get really strong guarantees in D, you declare your functions pure,
nothrow, and @safe. The nothrow means no exceptions are thrown and @safe means
all the low-level tricks (casts,assembly,etc) to break type safety are
disabled.

~~~
wyager
>All languages I know (e.g. Haskell) make concessions to pragmatism. For
example, even pure function can somehow create debug output.

From the Debug.Trace docs: "should _not_ be used in production code."

>Every memory allocation does mutate global state.

Yes, Haskell is approximately pure just like computers are approximately
Turing machines. Computers are technically FSMs, but they're practically so
close to Turing machines that we usually don't care. Haskell is so close to
pure that we don't care. It's also guaranteed to be semantically pure, until
you start to run into those edge cases where computers don't act like Turing
machines (i.e. when you run out of RAM).

>It removes the need allocate a return image or wrap computations in monads
and thunks.

No one is arguing that impurity/mutability is (frequently) useful. I'm just
arguing that it's disingenuous to call what you've described "pure", or that
this extra "purity" is very useful.

------
2color
Walter Bright is indeed a really bright mind. Having worked with D recently, I
really enjoyed the richness and empowerment the D language offers.

I believe the recent rising interest in functional languages is in part due to
the elegant blend of expressiveness and performance. Performance is always a
delicate topic nevertheless there are some aspects of functional languages
which tend to make them more performant.

------
a0
There is also a good article about purity in D by David Nadlinger, who is one
of the core developers of LDC (LLVM D Compiler):

\- [http://klickverbot.at/blog/2012/05/purity-
in-d/](http://klickverbot.at/blog/2012/05/purity-in-d/)

~~~
dbaupp
(For whatever reason HN is nonstandard and includes the trailing >; working
link: [http://klickverbot.at/blog/2012/05/purity-
in-d/](http://klickverbot.at/blog/2012/05/purity-in-d/) )

------
smegel
> This is why a cast to immutable is not allowed in D code marked as @safe.

It's an interesting design decision that D code is (presumably) @unsafe by
default.

~~~
WalterBright
Yes, although one can explicitly mark code as @system. (I've never liked the
"unsafe" attribute, as it implies the code is actually broken.)

Safety is something that becomes more desirable the larger and more complex a
program is. I wanted D to also be convenient to use for quick, simple programs
without burdening the user with having to add annotations.

------
bjz_
It is unfortunate that the length of the `immutable` seems to ergonomically
discourage its use. I know it's really hard to go back on language design
decisions, but have there been any thoughts about providing a shorter
alternative?

~~~
WalterBright
It used to be called "invariant". We found ourselves constantly explaining to
people that "invariant" types were immutable.

Bowing to the obvious, we changed it to "immutable". This has been highly
successful in that people immediately understand it.

Nobody ever found a shorter, equally clear term.

~~~
bjz_
Yeah - naming things is hard. I agree that `immutable` is clearer than
`invariant`. I would suggest `imm`, but that is damn ugly and more opaque. :(

------
bibonix
Why not get rid of mutable data in the first place? That would make this
language (and my others) much cleaner.

