digitalmars.D - Recommendation: "functional" keyword
- Sean Eskapp (4/4) Jan 09 2011 I recommend that there be a "functional" keyword, which when applied to
- Simen kjaeraas (4/8) Jan 09 2011 What is the difference between this and pure?
- Sean Eskapp (3/3) Jan 09 2011 Functional functions could not modify ANY data, including explicitly all...
- Simen kjaeraas (13/18) Jan 09 2011 I don't think I understand this. pure functions modify no data except
- Sean Eskapp (3/3) Jan 09 2011 It's a programmer contract, nothing more. It forces the code to be funct...
- Tomek =?ISO-8859-2?Q?Sowi=F1ski?= (9/13) Jan 09 2011 Immutably (strongly) pure (pure + all arguments immutable) functions bre...
- Sean Eskapp (6/7) Jan 09 2011 I meant what I said, and I said what I meant. Stack allocated implicitly...
- Jonathan M Davis (19/28) Jan 09 2011 You can declare variables in at least some functional languages. Take Ha...
- Andrei Alexandrescu (16/23) Jan 09 2011 You may always use immutable to enforce such a contract.
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
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
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
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
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
Sean Eskapp napisa=B3:It's a programmer contract, nothing more. It forces the code to be functi=onal, notprocedural. 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
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
On Sunday 09 January 2011 14:31:11 Sean Eskapp wrote: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 DavisThat'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
On 01/09/2011 04:31 PM, Sean Eskapp wrote: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. AndreiThat'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