www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Recommendation: "functional" keyword

reply Sean Eskapp <eatingstaples gmail.com> writes:
I recommend that there be a "functional" keyword, which when applied to
functions, would not allow them to modify existing data, or call impure
functions. This would imply pure.

Thoughts?
Jan 09 2011
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Sean Eskapp <eatingstaples gmail.com> wrote:

 I recommend that there be a "functional" keyword, which when applied to
 functions, would not allow them to modify existing data, or call impure
 functions. This would imply pure.

 Thoughts?
What is the difference between this and pure? -- Simen
Jan 09 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
Functional functions could not modify ANY data, including explicitly allocating
variables. Although, come to think of it, this wouldn't imply pure, as they
should
still be allowed to read global data and call impure functions.
Jan 09 2011
parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Eskapp <eatingstaples gmail.com> wrote:

 Functional functions could not modify ANY data, including explicitly  
 allocating
 variables. Although, come to think of it, this wouldn't imply pure, as  
 they should
 still be allowed to read global data and call impure functions.
I don't think I understand this. pure functions modify no data except for potential allocation and non-const ref parameters (which make the function weakly pure). Immutable (strongly) pure functions seem to match your charter except for the 'no allocation' part. However, your acceptance of calling impure functions means this would be non- transitive. There have been suggestions that D add a keyword for 'no heap allocation' ( noheap, I think), which in combination with immutable pure would cover the no allocation part, as well as the no modification part. Next question: What does this keyword add, that noheap would not? -- Simen
Jan 09 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
It's a programmer contract, nothing more. It forces the code to be functional,
not
procedural. Just like const and  safe are simply programmer contracts,
functional
would mean no explicit stack allocation, except that allocated in called
functions.
Jan 09 2011
parent reply Tomek =?ISO-8859-2?Q?Sowi=F1ski?= <just ask.me> writes:
Sean Eskapp napisa=B3:

 It's a programmer contract, nothing more. It forces the code to be functi=
onal, not
 procedural. Just like const and  safe are simply programmer contracts,
Immutably (strongly) pure (pure + all arguments immutable) functions break = D onto functional grounds.
 functional would mean no explicit stack allocation,
That's.. ehem.. quite limiting. :) (you probably meant heap)
 except that allocated in called functions.
Like Simen said, this is a matter of whether noheap is useful enough to be= included or not. --=20 Tomek
Jan 09 2011
parent reply Sean Eskapp <eatingstaples gmail.com> writes:
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!
Jan 09 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 09 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/09/2011 04:31 PM, 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 may always use immutable to enforce such a contract. Walter and I introduced the relaxation that private transitory variables are allowed inside pure functions deliberately, and we take great pride in it. I personally consider the desideratum of "writing functional code", when taken to extremes, as damaging and devoid of meaning as setting out to write "object-oriented code" or "generic code" at all costs. Good functional code is not feel-good. It means what it says - functions with functional semantics. Private transitory variables are extremely useful because they make it easy to implement a variety of algorithms without contortions that are typical of FP, such as threading state as additional function parameters when implementing Fibonacci correctly, or using a helper function to implement the factorial function correctly. I strongly believe that we've hit a great sweet spot there, and that there will be lasting influence following this relaxation. Andrei
Jan 09 2011