Actually, it looks like it's a rather plain event loop. I think that's the point, a really, really simple incarnation of (a set of) state machine(s) in C code.
For background on the semantics of statecharts and a bit of computer science history, see the following papers and book by Prof. David Harel (the inventor of statecharts) and his collaborators:
Just in time for people realizing that holding onto lots of state is actually a code-design smell and that functional paradigms should be used as much as possible instead!
internally message passing, futures and actors are all about state.
especially in erlang and scala. the libraries just wrapping that state so you don't need to care about.
also there is always state. look at the io front there your application needs to deal with state, if you are using fp your program maybe doesn't contain state. but the public api mostly deals with it.
Functional programming is about carefully managing your state. Ideally, you want to separate the pieces with the complicated logic, from the pieces that do the state persisting. Then each piece can do one thing and do it well.
There are lots of useful stateless services. But that's the nirvana, and not possible with all things you might want to offer.
Predictable reliability is relevant, certainly. Safety critical systems are frequently hard real-time,[0] by definition resource-constrained.
Aspects of functional paradigms are good for safety critical systems, e.g., using pure functions when possible, when it leads to more predictable and testable systems. Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.
[0] I'm hedging here with frequently, but I'm having trouble thinking of safety critical systems that aren't hard real-time off the cuff… perhaps supervised expert systems, say an automated pathology platform, might count?
> Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.
What you'd want is not a Turing complete language by default, but one that's guaranteed to halt. (And only have Turing complete bits as a fallback, just like unsafePerformIO today.)
Primitive Recursion might be a good limited but useful model of computation. Or something along the lines of Agda.
With such a more restricted notion, recursion doesn't necessarily have to be compiled to a stack.
I have done functional programming (FP) with Haskell (including professionally) for years, and I think this notion is misguided.
One of the core principles of FP is about state. However, I believe it is to think very carefully about state and be very explicit about how you handle it rather than performing ad-hoc mutations. That often means avoiding state, but many problems require maintaining state.
State machines can be a great tool to be explicit about state management to the point that you can have a specification for how state behaves.
Also, constraint of side effects at the language level allows powerful things like... time-traveling debuggers (does GHC provide anything like this, btw? Because it probably could...)
It amazes me how often programmers can talk about state machines and functions while concurrently pretending that mathematics is, largely, something that either need not be discussed or is of secondary concern.
24 comments
[ 4.9 ms ] story [ 67.6 ms ] threadThe STATEMATE Semantics of Statecharts, 1996
http://www.wisdom.weizmann.ac.il/~harel/SCANNED.PAPERS/Seman...
Modeling Reactive Systems with Statecharts: The STATEMATE Approach, 1998
http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...
The Rhapsody Semantics of Statecharts (or, On the Executable Core of the UML), 2004
http://www.wisdom.weizmann.ac.il/~harel/papers/RhapsodySeman...
Statecharts in the Making: A Personal Account, 2007
http://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.H...
In the second example, you stand on firmer ground though.
also there is always state. look at the io front there your application needs to deal with state, if you are using fp your program maybe doesn't contain state. but the public api mostly deals with it.
There are lots of useful stateless services. But that's the nirvana, and not possible with all things you might want to offer.
Aspects of functional paradigms are good for safety critical systems, e.g., using pure functions when possible, when it leads to more predictable and testable systems. Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.
[0] I'm hedging here with frequently, but I'm having trouble thinking of safety critical systems that aren't hard real-time off the cuff… perhaps supervised expert systems, say an automated pathology platform, might count?
What you'd want is not a Turing complete language by default, but one that's guaranteed to halt. (And only have Turing complete bits as a fallback, just like unsafePerformIO today.)
Primitive Recursion might be a good limited but useful model of computation. Or something along the lines of Agda.
With such a more restricted notion, recursion doesn't necessarily have to be compiled to a stack.
Not if one codes towards TCO (Tail Call Optimization): http://stackoverflow.com/questions/310974/what-is-tail-call-...
One of the core principles of FP is about state. However, I believe it is to think very carefully about state and be very explicit about how you handle it rather than performing ad-hoc mutations. That often means avoiding state, but many problems require maintaining state.
State machines can be a great tool to be explicit about state management to the point that you can have a specification for how state behaves.
Also, constraint of side effects at the language level allows powerful things like... time-traveling debuggers (does GHC provide anything like this, btw? Because it probably could...)
http://elm-lang.org/blog/time-travel-made-easy