pure or not pure?

[Janice Caron]

On 10/04/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> So your solution is, create a duplicate array that is never used again,

If you need to modify it, then it needs to be mutable, so a heap
allocation is unavoidable in any case.

>  thereby increasing the runtime

No, /decreasing/ the runtime, because the construction of the
invariant array only has to happen ONCE. (Conceptually, it happens
every time you call the function, but that's the beauty of functional
programming. The compiler is able to cache things and reuse them).


> Of course functional programming languages have mutable data.

Haskell doesn't.

>  They just
>  don't have SHARED data.

Haskell has no mutable data at all, only constants. In Haskell, you cannot do

    x = x + 1

because x, once assigned, keeps its value until it goes out of scope.
Now, I'm not saying that D needs to be that extreme. I'm only saying
that to get the benefits of FP, you have to hand over a certain amount
of control to the compiler, to the language. You no longer get to
choose the order of evaluation. You cannot be certain what will and
what won't be caller. You are no longer in /any/ position to estimate
execution time on the basis of what will or will not be called, or
when, or in what order.

Assuming the compiler is smart enough to make all the optimizations
that FP permits it to make, this is a plus, not a minus.


>  We need immutable data in D because

No one is arguing against that position.


>  But data that isn't shared shouldn't need to be immutable.

Or that one.


>  So let me restate: not having the ability to pass around UNIQUE mutable heap
> data to and from pure functions is going to limit severely the usefulness of
>  pure functions.

I disagree - partly, because the compiler cannot statically verify
uniqueness, so you would immediately be compromising the ability of FP
to strongly typecheck everything, thereby robbing the compiler of the
guarantees that it needs to ensure fast and crash-free
multiprocessing. But mostly because FP requires a different way of
thinking about things, and trying to force it to accomodate non-FP
paradigms because they sit well with the way you think about problems
just isn't playing the game. You have to trust that the compiler a
little more. It can optimise better - you just have to keep your
fingers crossed that it actually will!