thma / ltupatternfactory Goto Github PK

Builder Pattern / Fluent API with comonads:

• http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html
• https://chshersh.github.io/posts/2019-03-25-comonadic-builders

From a link in the current version of the typeclassopedia: https://wiki.haskell.org/Why_not_Pointed%3F

https://pdfs.semanticscholar.org/c4ce/14364d88d533fac6aa53481b719aa661ce73.pdf
file:///C:/Users/mahlerth/Downloads/figueroaAl-foal2013.pdf
https://hal.inria.fr/hal-00763695/document

http://blog.ezyang.com/2010/05/design-patterns-in-haskel/
http://www.cs.ox.ac.uk/jeremy.gibbons/publications/hodgp.pdf
https://staticallytyped.wordpress.com/2013/03/24/gang-of-four-patterns-with-type-classes-and-implicits-in-scala-part-2/

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update actions/cache action to v4
• Update actions/checkout action to v4

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The explanation starts off well, comparing the strategy design pattern to function pointers in structured programming, interfaces in OO and higher order functions in FP, but it derailed by shifting attention to the client of a strategy and ultimately comparing it to functors and concluding: "namely the injecting of a function into a computational context and its execution in this context".

As stated in GoF under the Strategy Design Pattern:

"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

Attention to "encapsulates" and "lets the algorithm vary independently from clients that use it". By "use it" we should understand to make a call or to execute such algorithm. A few sections down we read:

"We can avoid these problems by defining classes that encapsulate different linebreaking algorithms. An algorithm that's encapsulated in this way is called a strategy."

Notice that the definition of the strategy pattern is independant of the "computational context and its execution in this context" as this is more of a way to model the aplication than to execute the modeled aplication.

The explanation also misrepresents the strategy pattern in Java by creating multiple interfaces when the pattern clearly defines only one interface for the many "strategies" of computation that will be selected and eventually injected by another pattern, into a context of execution. The very notion of the Strategy Design Pattern could be said to be averse to composition and this example does the exact opposite.

I suggest looking into Composite, Proxy and Decorator design patterns as good options of "injecting of a function into a computational context and its execution in this context".

It seems the Interpreter OO pattern is more about interpreting of arbitrary ADTs in FP, in particular with help of Free Monad.

Hi thma,

great project! It's important to connect the OO world and the FP world. Doing so by matching design patterns to type classes should give valuable insights.

In the Section "Functor -> Strategy" there is a comment about currying

 context :: Num a => (a -> a) -> [a] -> [a]
 context f l = map f l
  -- according to the rules of currying this can be abbreviated to:
 context = map

Currying is taking a function from (a, b) -> c to a -> b -> c, so I'm not sure that just leaving the function arguments is really currying. It is rather related to the pointfree style.

So maybe the comment should rather say "using point free style", or "in Haskell it is possible to not write the arguments".

Best,
Johannes

The pipeline example implementation breaks the monad laws! You can't have a counter on the number of binds, because that breaks the law that (>>= return) === id.

Implicit parameters in Haskell
Dependency injection using the Reader monad (F#)