Modern Functional Programming: The Onion Architecture • Hacker News Board

Re: Modern Functional Programming: The Onion Architecture

#11

Post by asciihacker » Thu, Sep 29, 2016, 2:59 PM UTC

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

I'm enjoying watching the boundaries talk, especially when he converts the serial code the concurrent code using actors.

Re: Modern Functional Programming: The Onion Architecture

#12

Post by VeejayRampay » Thu, Sep 29, 2016, 3:02 PM UTC

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

I'd like to use the occasion that I'm really waiting for the video of his talk "Ideology" given at StrangeLoop 2015.

Re: Modern Functional Programming: The Onion Architecture

#13

Post by RodericDay » Thu, Sep 29, 2016, 3:10 PM UTC

VeejayRampay wrote: post #12

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

I'd like to use the occasion that I'm really waiting for the video of his talk "Ideology" given at StrangeLoop 2015.

Same, but for whatever he talked about in PyCon 2015

Re: Modern Functional Programming: The Onion Architecture

#14

Post by mbrock » Thu, Sep 29, 2016, 3:13 PM UTC

rtpg wrote: post #9

bad_user wrote: post #7

> Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation. That is not true and this overselling of the Free monad is hurting the concept. The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a…

Maybe this is a bit trite, but isn't the ordering given in Free simply the order of the code? At what stage does loss of information happen.

Yeah, the free monad structures involve lots of lambdas. It's not so much that information is "lost", more that you cannot see beyond the next lambda abstraction.

From a DSL perspective, it's like you can only inspect the program so far as to know the next statement in the "do" block. To see what the next statement will be, you need to actually evaluate the current one.

Instead of free monads, if you want very analyzable structures, look at free applicative functors.

"Applicative functors are a generalisation of monads. Both allow the expression of effectful computations into an otherwise pure language, like Haskell. Applicative functors are to be preferred to monads when the structure of a computation is fixed a priori. That makes it possible to perform certain kinds of static analysis on applicative values. We define a notion of free applicative functor, prove that it satisfies the appropriate laws, and that the construction is left adjoint to a suitable forgetful functor. We show how free applicative functors can be used to implement embedded DSLs which can be statically analysed."

http://arxiv.org/abs/1403.0749

Re: Modern Functional Programming: The Onion Architecture

#15

Post by junke » Thu, Sep 29, 2016, 3:13 PM UTC

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

At the lowest levels, the pattern can be reversed: you provide a nice functional shell around a little bit of imperative core (e.g. implementing "map" with a loop).

Re: Modern Functional Programming: The Onion Architecture

#16

Post by KirinDave » Thu, Sep 29, 2016, 3:23 PM UTC

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

I was quite disappointed the author chose not to cite Bernhardt's work, as this is pretty clearly derivative of that talk and other work in the community around this design.

I'm certain I've heard Hickey talk about it a few years ago as well. Trying to remember where.

Re: Modern Functional Programming: The Onion Architecture

#17

Post by KirinDave » Thu, Sep 29, 2016, 3:33 PM UTC

bad_user wrote: post #7

> Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation. That is not true and this overselling of the Free monad is hurting the concept. The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a…

Maybe John is attributing more magic to the common free monad patterns than is actually there? Certainly I had stars in my eyes when I first read:

https://people.cs.kuleuven.be/~tom.schrijvers/Research/paper...

> then you'd be able to build something like .NET LINQ on top of Free. But you can't.

You sort of can. You could build an interpreter of Linq commands and then have an executor interpret that. Which I suppose could be argued is making Linq. :)

Re: Modern Functional Programming: The Onion Architecture

#18

Post by KirinDave » Thu, Sep 29, 2016, 3:34 PM UTC

junke wrote: post #15

slashdotdash wrote: post #5

Gary Bernhardt describes a similar architecture using a "Functional Core, Imperative Shell" in his Boundaries talk[1]. "Purely functional code makes some things easier to understand: because values don't change, you can call functions and know that only their return value matters—they don't change anything outside themselves. But this makes many real-world applications difficult: how do you write to a database, or to…

At the lowest levels, the pattern can be reversed: you provide a nice functional shell around a little bit of imperative core (e.g. implementing "map" with a loop).

This kind of abstraction layer is really challenging though unless you're totally aware of the extent of your imperative code's side effects.

Re: Modern Functional Programming: The Onion Architecture

#19

Post by lmm » Thu, Sep 29, 2016, 3:36 PM UTC

mbrock wrote: post #14

rtpg wrote: post #9

Earlier quoted context omitted.

Maybe this is a bit trite, but isn't the ordering given in Free simply the order of the code? At what stage does loss of information happen.

Yeah, the free monad structures involve lots of lambdas. It's not so much that information is "lost", more that you cannot see beyond the next lambda abstraction. From a DSL perspective, it's like you can only inspect the program so far as to know the next statement in the "do" block. To see what the next statement will be, you need to actually evaluate the current one. Instead of free monads, if you want very analyz…

The problem is that applicative functors aren't powerful enough to allow computations that depend on previous results. I suspect what we want is something like free ArrowChoice, but I'm not aware of any work in that direction.

Re: Modern Functional Programming: The Onion Architecture

#20

Post by lmm » Thu, Sep 29, 2016, 3:40 PM UTC

rtpg wrote: post #9

bad_user wrote: post #7

> Free monads permit unlimited introspection and transformation of the structure of your program; Free monads allow minimal specification of each semantic layer, since performance can be optimized via analysis and transformation. That is not true and this overselling of the Free monad is hurting the concept. The Free monad is nothing more than the flatMap/bind operation, specified as a data-structure, much like how a…

Maybe this is a bit trite, but isn't the ordering given in Free simply the order of the code? At what stage does loss of information happen.

Monad linearizes the call graph; the effects of f(g, h) have to look the same as those of f(g(h)). In particular your interpreter can't parallelize, because it can't tell whether there's a data dependency between one effect and the next or not.