Recommendation: "functional" keyword

Jonathan M Davis jmdavisProg at gmx.com
Sun Jan 9 17:36:35 PST 2011


On Sunday 09 January 2011 14:31:11 Sean Eskapp wrote:
> >That's.. ehem.. quite limiting. :) (you probably meant heap)
> 
> I meant what I said, and I said what I meant. Stack allocated implicitly
> would be fine, but explicit stack allocation, like declaring variables,
> doesn't happen in purely functional languages.
> 
> Personally, I like being able to impose this contract on myself to write
> functional code, just like I like being able to use const and @safe.
> Apparently I'm in the vast minority!

You can declare variables in at least some functional languages. Take Haskell's 
let for example. Haskell is purely functional and yet you can effectively declare 
a local variable. You can't mutate it, but it's a local variable.

D is not a functional language, nor is it trying to be one. It has added pure 
and immutable allowing you to better program in a functional manner, primarily 
with multi-threading in mind. What we have does that and overall does it quite 
well. Disallowing local variables gives you _no_ benefit whatsoever that I can 
see, and at least some functional languages effectively allow it anyway.

D already has purity, which gives you the ability to program functionally. If 
you want to be overly-restrictive and not use local variables, that's your 
perogative, but that has no effect whatsoever on the result of the function, so 
there's no reason to enforce that a function behave that way even if it were 
actually desirable for some reason. If something affects the internal behavior of 
a function but not its result (including how it affects all variables external to 
it, not just its return value), then there's no reason to enforce that in the 
function's signature. That's encapsulated in the function, and the caller 
doesn't care.

- Jonathan M Davis


More information about the Digitalmars-d mailing list