Hacker News Reader

Comment by ghswa | Hacker News Reader

I don't agree that managing effects is over the top per se however the use of monads feels over the top for pretty much everything!

It's always struck me as strange that value (as in a typical type system) and effects would be controlled through the same system. The type signature of a function and it's effects seem very much orthogonal to me.

If we want to be controlling side effects then we really ought to be using a separate effect system[1]. There's a scala plugin demonstrating this (although I've not tried it)[2].

With separate type and effect systems I should be able to define a pure function fib(n) and call it like this fib(getValueFromUser()) that is without having to use special operators to get at the value which can only be used in certain contexts a la Haskell.

[1] http://en.wikipedia.org/wiki/Effect_system

[2] https://github.com/lrytz/efftp/wiki

View on HN

I think a separate effect system would be needless specialisation. The IO monad has shown that effects can be reasonably well encoded in the existing type system, the problem is just that composing lots of effects starts to get complicated. I think any solution should involve extending the type system in a general way, or even just providing some kind of syntactic sugar to hide the noise from more complicated types.

For Haskell you're absolutely right however I was responding to the OPs comment that controlling effects in general is over the top.

The issue of composing effects, along with the widespread fear of monads, are enough for me to conclude that monads are not the best way to control effects.

I don't remember ever seeing any solutions other than monads and deprecate effect systems, hence my preference for the later.

The progress that has been made in Haskell in the past decade leads me to believe that the issues with the current system can be solved with better abstractions, and possibly new syntax. Or if the solution isn't possible in Haskell, that it will be born of a similar philosophy.

I don't yet know whether fear of monads is something the programming community will grow out of, or whether there is a more fundamental reason people have difficulty with them. From what I've seen, the response of most people on finally "getting" monads is "Wait that's it?", so I'm inclined to believe a significant part of the hurdle is the fear itself.

    x = fib(getValueFromUser())

x is not pure, but fib is. OK, the compiler can figure that out without requiring the programmer to write a special "bind" operator.

How about this:

    dofib(argumentProvider) = fib(argumentProvider())
    dofib(lambda: 1)  // pure
    difib(getValueFromUser) // effectful

Is dofib pure or not? That depends on the value of argumentProvider cannot be determined statically.

Using the mechanic employed by the scala plugin I linked to[1], dofib would be annotated with pure(argumentProvider). dofib itself is pure however, at each call site, it has the effect of its argument for that call. This is consistent with your example.

[1] https://github.com/lrytz/efftp/wiki/Relative-Effects

edit: That's effectively (sorry!) higher-order effects, behaving just as you'd expect.

Is dofib pure or not?

Food for thought:

1. The easy but limited solution is that this code doesn't compile, because argumentProvider must have a single type/effect and you couldn't have both a pure and an impure function with that type/effect.

2. Is purity that important? Ultimately we care about avoiding our programs doing unintended things, and often effects are just fine as long as they don't misbehave in some way. Purity is a means to an end.

3. It's fascinating to extend the ideas of generic programming from mainstream type systems to effect systems. I suspect there is a lot of potential benefit to be had if we can figure out how to do this without introducing a lot of boilerplate code, in the same way that we can write code using generic types to various degrees today but have type inference spare us a lot of keyboard bashing.

Effect inference has already been done: http://research.microsoft.com/apps/mobile/showpage.aspx?page...

I doubt we'll see anything like this in a mainstream language anytime soon.

That's an interesting case I hadn't seen before, so thanks for the link.

Some of the related pages don't seem to be available at the moment, but from what I could see it looks as if that approach still gets hung up on questions of decidability, and doesn't have a very powerful concept of the regions where effects apply, which has been another interesting aspect of the wider research so far. It's good to see someone else working on the field, though.

dofib is a pure, higher order function. dofib(getValueFromUser) always returns the same (non-pure) function, but it is always the same. If the argument is provided by another variable, then you need to look up the chain, and would likely have the type/effect system force you not to mix pure/impure functions in the possible parameters, or if you do mix them, call dofib(f) impure.

Well, if you're working in a proper language with an effect system, then dofib is parametrically effect-polymorphic on the effect of its input function.

An effect system cannot express what transformers can. Consider the difference between StateT s Maybe and MaybeT (State s).

LINQ (C#) seems pretty awesome and not over-the-top, and I believe it's foundation is monad-based. Best example I can think of.

Reply on news.ycombinator.com