Native vs. HTML5 for web development? Why native might be the right choice

Sky-Tiger

he easiest one, the apply function, embeds an input value in a function context. This fresh context should be able to restore the value any time. A sort of constant function.

Regarding the flatten method, typically what we expect is to flatten a function producing a function ((A) ⇒ (A) ⇒ T seen as (A) ⇒ ((A) ⇒ T)) to a function producing a simple value. That is exactly the purpose of the new function we created, applying successively the possible input x value to each of the function argument.

Armed with our implementations we now can derive a full Applicative Functor implementation. As for the State Monad pattern, the Applicative Functor implementation accepts a single type parameter  Applicative[M[_]].
The type of functions we are working with are double parameter type constructor . In our working context, the type of returned values is the the embedded type in our Monad definitions. The function input parameter type defines a context from within the embedded type is extracted, therefore we must freeze the input type somehow. This is when type lambda comes into the place:

Sky-Tiger

We basically defines two operations accepting an input parameter each, and return the result of the combined functions. The more interesting part being that each function reads from the same input source. I guess that's why we call the pattern the "Reader" Monad.

How many times did we encounter this situation when we had to apply different operations onto an input context from which we aimed to extract, then process values ?
The most recent example that came to my mind was setting up an environment from accessible configuration information. In his book, Joshua Suereth explains how to produce then combine optional Config instances while building an application. Starting from there and using our new pattern just see how we can simulate the whole scenario:

  case class Config[T](data: T)

  implicit object ApplicativeConfig extends Applicative[Config] {
    def apply[T](data: T) = Config(data)

    def flatten[T](m: Config[Config[T]]) = m.data

    def map[T, P >: T, U](source: Config[T])(f: (P) => U) = Config(f(source.data))
  }

  case class Connection()
  case class Datastore()
  case class Application()
  case class Environment(datastore: Datastore, application: Application)

  def connection(map: Map[String, String]): Config[Connection] = Config(Connection())
  def datastore(conn: Config[Connection])(map: Map[String, String]): Config[Datastore] = Config(Datastore())
  def application(map: Map[String, String]): Config[Application] = Config(Application())

  def build = (a: Application, d:  Datastore) => Environment(d, a)

  def configBuilder = for {

    conn <- connection _
    store <- datastore(conn) _
    app <- application _

  } yield (build:@:app:*:store)


  println(configBuilder(Map()))

Sky-Tiger

In our scenario we build some environment using connection, datastore, and application configuration. The configuration (aka Config case class) is a container manageable using an implicit Applicative Functor.

the configBuilder method implements a complete environment setup process. We use our Reader Monad implementation in order to extract from a unique source
a connection configuration
a datastore configuration from the connection configuration
application configuration
Then we build a complete environment using from single source of properties (a Map here). The environment is set using the sugar syntax we defined around Applicative functors in a previous post.


Now, we know how to separate the concern of what we create from a single source from how to process it. Although the example remains simplistic, we have in our every day life as programmers, opportunities to clutter the code while applying different processes to  a same immutable input (input analysis, input validation, information display etc.). The Reader Monad can save the day gathering in the same comprehension the whole process.

Sky-Tiger

In our scenario we build some environment using connection, datastore, and application configuration. The configuration (aka Config case class) is a container manageable using an implicit Applicative Functor.

the configBuilder method implements a complete environment setup process. We use our Reader Monad implementation in order to extract from a unique source
a connection configuration
a datastore configuration from the connection configuration
application configuration
Then we build a complete environment using from single source of properties (a Map here). The environment is set using the sugar syntax we defined around Applicative functors in a previous post.


Now, we know how to separate the concern of what we create from a single source from how to process it. Although the example remains simplistic, we have in our every day life as programmers, opportunities to clutter the code while applying different processes to  a same immutable input (input analysis, input validation, information display etc.). The Reader Monad can save the day gathering in the same comprehension the whole process.