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