Hacker News Reader

Comment by wrong_variable | Hacker News Reader

If you are interested in learning about Algebraic structures and group theory from a very practical standpoint I highly recommend

https://github.com/fantasyland/fantasy-land

Also - does anyone show me a practical usecase of the reader monad ? cant you just use partial functions ?

if I am not mistaken isn't reader monad just :

foobar.config ({'name':'hello'});

foobar.run ({'age':'34'});

View on HN

The reader monad is like read-only thread-local storage. (State or ST would be thread local storage). It provides a command to get the "current state"

  function f() {
    var m = getState().chain(state => {
      // ...
    })
    return m;
  }

or with generators acting like do syntax replacement:

  var f = wrapped(function* () {
    var state = yield getState();
    // ...
    return;
  });

At the end you get an object that contains an unexecuted sequencing of computations that you can run with any state. For example you could run it from a HTTP route handler with the current user contained in the "state":

  var m = f();
  m.runWith({currentUser: request.user})

and now you have access to the user without passing it around everywhere.

All the other analogies in this thread are wrong in terms of what the real API looks like. The real API looks almost exactly like Promises, with `chain` instead of `then`.

This in turn also explains why monad transformers are so important. Having access to just the current user w/o passing it around isn't very useful if e.g. you can't do IO, but having both - now we're talking!

I do not understand how the reader monad is different than promise.

It seems the reader monad just delays execution of some code until you call 'runWith' and you can define state variables throughout your code before calling runWith.

Thats precisely what it does, yes. Its different than a promise because the implementation is different (everything is done synchronously, and getState() returns an action object which then the implementation works on. The result of doing runWith() is also immediately available (not possible with async IO):

  var result = m.runWith(...)

Other than that its almost exactly the same. And so are other monads. The Array monad (that is, if JS arrays actually had that method, which they don't)

  var m = [1,2,3]
    .chain(x => [x, x * 10])
    .chain(y => y < 2 ? [] : [y])

result: [10,2,20,3,30]

Same API (monad), totally different functionality.

so monads are just a way to define an api ?

so anything that is like this :

values = ['coffee','water']

AfterWebSocket = values.sendToWebSocket()

AfterWebSocket.compute (eachValue => x*2)

is that it ?

It has to be the chain method and it has to act in such a way that you pass a function that returns an object of the same type.

For array chain takes a function that returns an array. For promises, chain takes a function that returns a promise object. For Reader, chain takes a function that returns another reader object.

Here is a complete class Reader:

  class Reader {
    constructor(computation) {
        this.computation = computation;
    }
    runWith(data) {
        return this.computation(data)
    }
    chain(readerReturningFn) {
        return new Reader(data => readerReturningFn(this.computation(data))
                                  .runWith(data))
    }
    static of(val) {
        return new Reader(data => val)
    }
    static getState() {
        return new Reader(data => data)
    }
  }

Here is how you can use it:

  var r = Reader.of(5).chain(x => Reader.getState().chain(y => Reader.of(x + y)))
  r.runWith(2)
  > 7

For it to be useful, you want ReaderT, a monad transformer which takes another monad (such as Future) and creates a new monad that provides functionality from both. This gets fairly complicated fairly quickly :D But the result is also a monad, which means it will have the same familiar `chain` based API.

And yes, monads in programming are this simple. Mathematical monads are a wider generalisation of computing monads (just like Iterable would be something more general in the real world, not "things with a next() method that acts like this"), but in terms of programming its a shared API (chain) that acts in a certain way (chains to another object of the same type and flattens one level, whatever that means for the concrete implementation)

So its all just about types, ?

More like a specs that if people follow the world would be a better place ?

what is a monad transformer ?

I understand your code - but fail to see why its so useful :(

Yeah, its about the type / interface / protocol. But they really are very, very useful. There are just so many problems that can be solved with it.

For example there can be a GraphQL monad. Instead of Promise.all you would use GraphQL.parallel(otherMonads), and the implementation can transform that to a single request to the server instead of multiple ones.

Similarly there can be an ORM monad that avoids the n+1 queries problem. parallel(Users.get(id)).chain(users => ...) will transform the parallel query to a single SELECT ... IN query.

Also, have you tried passing the current user around in server side code, everywhere? Its really tedious to do, and Reader solves that!

A monad transformer is (more or less) a function that takes a monad class and returns a new monad class (yes thats the class object, not an instance). So if for example Future were a monad, and you wanted to add Reader functionality, you would create a new class PromiseWithReader:

  var FutureWithReader = ReaderT(Future)

Now you can use this monad to do both getState() and async IO operations within its chained functions.

  function getUserPosts() {
    return getState()
    .chain(state => Posts.getForUserId(state.user.id)) // cheating a bit here
  }

in the route handler:

  getUserPosts.runWith({user: req.currentUser})
  .fork(posts => res.json(posts))

The cool part is you can use getState() at any time to get the state. This will work no matter how deep your functions are: the example above is just with a single function, but that function can call another, which calls another, which calls getState() to get the user. But there is still no need to pass that user through all those calls. And if you use something like a State monad, you'll even be able to modify the contents of the state.

p.s. Future implementation, based on robotlolita's minimal Future class: https://gist.github.com/spion/b433a665ca51d6c38e9f

hey spion !

I read your post and sent you some messages on gitter, it seems you do not use gitter a lot :(

Sorry about that.

Here is an implementation of ReaderT, how it can transform a Future to provide "local readonly state", and a usage example:

https://gist.github.com/spion/b433a665ca51d6c38e9f

Since its JS, I also added automatic lifting, just to annoy Haskell programmers ;)

Reader fulfills a bunch of OO patterns. I like to think of it as "Environment", "Capability", "Configuration", etc., and is related in a way to Dependency Injection.

Basically, you have some computation/object that isn't complete without some "setup info" which, from the point of view of the code being written, is "just there". Like if you had a program that needed access to a particular interface, but you didn't want to manually pass it to every function that cares about it; instead you'd make an object with that interface as its state and write your program as methods on that object. That's just Reader in disguise.

In fact, C++ methods are basically in the Reader monad; they all have an implicit "this" argument which the compiler plumbs around for you.

Interestingly enough "Environment" is another name for the Reader Monad.

well, a 'reader' monad is a monad over a Function[A, B]. So yes, when you say 'the reader monad', what you (probably?) mean is the instance it operates on, which would be a function.

You use the reader monad the thread the same input to multiple functions that may also take additional intput, and also have their own outputs.

You have to keep in mind that since Monads are so common and useful, many languages have syntactic support for them. C#'s LINQ query syntax, scala for expressions and haskell 'do' are all 'monadic comprehension'.

So A reader Monad is similar to class inheritance. Where you provide a dependency ( like a inner class ).

The resulting class can also have other variables and inputs.

Is that a correct analogy ?

I think a better analogy with OO languages would be a Function object for which you've provided one of the arguments in its constructor.

Inheritance is more similar to monad transformers.

Yes, you can just use partial functions.

But partial functions are not always as clean as you think they are. When composing with pure functions for example, you'll save a lot of boilerplate lambdas if you use the monad.

I wrote a simple post showing the 3 main ways to pass state. Check it out! http://deliberate-software.com/haskell-state/

The Reader Monad lets you abstract away local state. You're on the right track with partial functions, but using a monad is cleaner (at least in Haskell...and I'd guess anywhere else). Essentially using the monad instead will let you remove all of the redundant function application you'd have to do otherwise. If you've managed to abstract this step away into a library, take a look at your abstraction. It's probably equivalent to Reader.

And check out ramda-fantasy while you're there!

Reply on news.ycombinator.com