3 ms·

FP decouples the AST (symbolic functions with input ports and an output port) from the evaluation context, which might be async, or sync, backpressured, statefu

FP decouples the AST (symbolic functions with input ports and an output port) from the evaluation context, which might be async, or sync, backpressured, stateful, exceptional, incremental/reactive ... mix-n-match whatever behaviors you want, all for the same abstract AST

samuell 6y ago
I actually didn't want to make this too much of an FP-bashing comment, as I find great use of many FP concepts, daily. I have yet to see an FP concept for composition though, that is as simple and generic in its implementation, as the FBP principles. I have sometimes thought FBP networks provide roughly the same function (pun not intended) as a monad, although I never seem to fully grasp what a monad is, so I can't tell for sure :o)
- dustingetz 6y ago
  Yes, dataflow with dynamic topologies (self-adjusting computation) forms a monad. If the "flowchart" is merely static, that forms an applicative. https://blog.janestreet.com/breaking-down-frp/ https://blog.janestreet.com/breaking-down-frp/ In my opinion, understanding the monad is essential to understanding how to fully separate an AST from its evaluation behavior. That is basically what a monad is, the monad is the computational structure that does that.
  - samuell 6y ago
    Thanks, that clarifies a lot!
dmbarbour 6y ago
I think most FP languages don't decouple AST from evaluation context. E.g. I cannot perform abstract interpretation on a function's AST, nor rewrite a function's AST for incremental computation, nor perform explicit partial evaluation during function composition by composing the ASTs. I only can access opaque `Input -> Output`. Also, FP algorithms developed for one evaluation context cannot easily be ported to another. They are implicitly entangled with assumptions. For example, I cannot evaluate a lazy algorithm in an eager evaluation context without paying a huge price. Adding back-pressure for list processing where a program was not designed for it would easily result in deadlock. Adding exceptions without adding unwind (or bracket, try/finally, etc.) to the existing program expressions will easily result in buggy code. I think your assertion might be true for some specific integrations of FP nodes into FBP. Is this what you mean?
- dustingetz 6y ago
  Today-era functional languages (so basically haskell and scala) don't do that at the "host PL" level, but you can model it in-band, and modeling embedded PLs is what most of the cool FP research for the last 5 years is all about. Free monad, tagless-final interpreters, etc. You make a DSL with abstract capabilities and then code your application in that. Any reified behaviors end up encoded into the type. I hear Facebook is using algebraic effects to model and track data access.
  - dmbarbour 6y ago
    FP is relatively convenient for metaprogramming, yes. GADTs and tagless-final encodings (or as I think of them, Church-encoded ASTs) are especially useful for this. But it wouldn't be a big difference if the host language was heavily imperative, so long as it favors immutable data structures. The FP aspect for this exploration of DSLs is much more social and cultural than technical. I think that if we really want to decouple AST from evaluation context, the main tool we'd need is to deconflate module 'import' into separate steps to 'load' a module's AST and 'integrate' definitions, allowing for intermediate processing. This requires some host language changes, elimination of module-global state, etc..

samuell 6y ago

I actually didn't want to make this too much of an FP-bashing comment, as I find great use of many FP concepts, daily. I have yet to see an FP concept for composition though, that is as simple and generic in its implementation, as the FBP principles. I have sometimes thought FBP networks provide roughly the same function (pun not intended) as a monad, although I never seem to fully grasp what a monad is, so I can't tell for sure :o)

dustingetz 6y ago
Yes, dataflow with dynamic topologies (self-adjusting computation) forms a monad. If the "flowchart" is merely static, that forms an applicative. https://blog.janestreet.com/breaking-down-frp/ https://blog.janestreet.com/breaking-down-frp/ In my opinion, understanding the monad is essential to understanding how to fully separate an AST from its evaluation behavior. That is basically what a monad is, the monad is the computational structure that does that.
- samuell 6y ago
  Thanks, that clarifies a lot!

dmbarbour 6y ago

I think most FP languages don't decouple AST from evaluation context. E.g. I cannot perform abstract interpretation on a function's AST, nor rewrite a function's AST for incremental computation, nor perform explicit partial evaluation during function composition by composing the ASTs. I only can access opaque `Input -> Output`. Also, FP algorithms developed for one evaluation context cannot easily be ported to another. They are implicitly entangled with assumptions. For example, I cannot evaluate a lazy algorithm in an eager evaluation context without paying a huge price. Adding back-pressure for list processing where a program was not designed for it would easily result in deadlock. Adding exceptions without adding unwind (or bracket, try/finally, etc.) to the existing program expressions will easily result in buggy code. I think your assertion might be true for some specific integrations of FP nodes into FBP. Is this what you mean?

dustingetz 6y ago
Today-era functional languages (so basically haskell and scala) don't do that at the "host PL" level, but you can model it in-band, and modeling embedded PLs is what most of the cool FP research for the last 5 years is all about. Free monad, tagless-final interpreters, etc. You make a DSL with abstract capabilities and then code your application in that. Any reified behaviors end up encoded into the type. I hear Facebook is using algebraic effects to model and track data access.
- dmbarbour 6y ago
  FP is relatively convenient for metaprogramming, yes. GADTs and tagless-final encodings (or as I think of them, Church-encoded ASTs) are especially useful for this. But it wouldn't be a big difference if the host language was heavily imperative, so long as it favors immutable data structures. The FP aspect for this exploration of DSLs is much more social and cultural than technical. I think that if we really want to decouple AST from evaluation context, the main tool we'd need is to deconflate module 'import' into separate steps to 'load' a module's AST and 'integrate' definitions, allowing for intermediate processing. This requires some host language changes, elimination of module-global state, etc..