4 ms·

Maybe common FP languages are missing a control structure somewhere that would encapsulate the progression from stable state to stable state (the transition of

Maybe common FP languages are missing a control structure somewhere that would encapsulate the progression from stable state to stable state (the transition of which is purely functional) while the glue between transitions is as free as procedural code? Let's take my field, HPC, as an example, the same would hold for game engines: There isn't really a reason why Kernels couldn't be functional and performant, in fact CUDA is in many ways a data oriented language, however outside the kernels there is often the need to swap pointers for example, so one can save unnecessary memory copies between timesteps. The data in question often tends towards tens or hundreds of gigabytes (the size of the cluster node memory), so you really don't want to allocate that fresh between kernels. I don't know enough of Haskell to decide whether Monads would be of any help, but these pure FP languages just don't seem to allow me to ask how something is going to perform and how to approach the maximum possible performance for a given algorithm, their syntax only seems to care about functional correctness.

dirkt 9y ago
Monads are actually the "missing" control structure that encapsulates progression from stable state to stable state, and moreover allows you to combine etc. those progressions in a functional fashion. If you look at the type signature of (>>=) (monadic bind), it says (>>=) :: Monad m => m a -> (a -> m b) -> m b which, if you instantiate m with a monad that represents state, you you can read as "given a progression 'm a' from state to state with return value of type 'a', and a function that uses this value to construct a progression from state to state with a return value of type 'b', then I can compose both progressions, and get a progression from state to state with return value 'b'". (These "return values" are used to transfer information from one progression to the next progression, and are the only thing that take a bit getting used to). So pure FP languages do allow you to specify step-by-step progression. Seen from this point of view, Alan Kay's statement 'there is no reason to invent “monads” in FP' is just nonsense, because he has no experience with pure FPLs, and seems to be only familiar with Lisp, which is a very impure ad-hoc FP. So while I agree with his conclusion "both OOP and functional computation can be completely compatible (and should be!)." (see e.g. Ocaml for a fusion of both concepts), and I am not particularly impressed by his reasoning.
- m_mueller 9y ago
  Thank you for your answer, but what about my specific example with pointer swapping? I‘d need a way to control memory handling in a procedural way in between pure state transitions. It probably goes further than that still - FP in general hides from me what happens with intermediate results on the hardware - I‘d need a way to have it use preallocated memory pools, because these operations are repeated in a very regular pattern (once per timestep or solver iteration) and thus always occupy the same memory. Versioning of previous states can (due to hardware limitations) only be done by file output. I‘ve never seen a pure FP language covering this because it seems to fundamentally go against purity principles, but as long as this is the case I reckon it‘s simply unusable for any but the smallest scale numerical applications.
- deleted 9y ago
  [deleted]

dirkt 9y ago

Monads are actually the "missing" control structure that encapsulates progression from stable state to stable state, and moreover allows you to combine etc. those progressions in a functional fashion. If you look at the type signature of (>>=) (monadic bind), it says (>>=) :: Monad m => m a -> (a -> m b) -> m b which, if you instantiate m with a monad that represents state, you you can read as "given a progression 'm a' from state to state with return value of type 'a', and a function that uses this value to construct a progression from state to state with a return value of type 'b', then I can compose both progressions, and get a progression from state to state with return value 'b'". (These "return values" are used to transfer information from one progression to the next progression, and are the only thing that take a bit getting used to). So pure FP languages do allow you to specify step-by-step progression. Seen from this point of view, Alan Kay's statement 'there is no reason to invent “monads” in FP' is just nonsense, because he has no experience with pure FPLs, and seems to be only familiar with Lisp, which is a very impure ad-hoc FP. So while I agree with his conclusion "both OOP and functional computation can be completely compatible (and should be!)." (see e.g. Ocaml for a fusion of both concepts), and I am not particularly impressed by his reasoning.

m_mueller 9y ago
Thank you for your answer, but what about my specific example with pointer swapping? I‘d need a way to control memory handling in a procedural way in between pure state transitions. It probably goes further than that still - FP in general hides from me what happens with intermediate results on the hardware - I‘d need a way to have it use preallocated memory pools, because these operations are repeated in a very regular pattern (once per timestep or solver iteration) and thus always occupy the same memory. Versioning of previous states can (due to hardware limitations) only be done by file output. I‘ve never seen a pure FP language covering this because it seems to fundamentally go against purity principles, but as long as this is the case I reckon it‘s simply unusable for any but the smallest scale numerical applications.
deleted 9y ago
[deleted]