Functional programming in D and some reflexion on the () optionality.

[David Piepgrass]

> The problem isn't about following haskell precisely or not (I 
> think we shouldn't). The problem is wanting to have everything, 
> and resulting in getting nothing.
>
> Let's take haskell as example. Function are all pure. So it 
> doesn't matter when a function get executed or not, and, as a 
> result, haskell don't need a explicit function call like () in 
> D.
>
> Some people find that great, and want it to be the case in D. 
> So D drop () usage.
>
> Now, as D don't enforce purity, when does the function get 
> executed is important. As a result, complicated scheme is 
> implemented to know when does the function get executed, wand 
> when it doesn't (You'll notice *4* families of scheme for that 
> in D).
>
> As a result, the design is overly complex, and defined nowhere. 
> Just to have that haskell feature, that work well in haskell 
> because of some other properties of the language D don't have.

What are the 4 "families of scheme to know when does the function 
get executed"?