5 ms·

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 st

by ghswa 13y ago

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 http://en.wikipedia.org/wiki/Effect_system [2] https://github.com/lrytz/efftp/wiki https://github.com/lrytz/efftp/wiki

gohrt 13y ago
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.
- ghswa 13y ago
  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 https://github.com/lrytz/efftp/wiki/Relative-Effects edit: That's effectively (sorry!) higher-order effects, behaving just as you'd expect.
- Silhouette 13y ago
  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.
  - ghswa 13y ago
    Effect inference has already been done: http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-us/projects/koka/ http://research.microsoft.com/apps/mobile/showpage.aspx?page... I doubt we'll see anything like this in a mainstream language anytime soon.
    - Silhouette 13y ago
      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.
- gizmo686 13y ago
  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.
- eli_gottlieb 13y ago
  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.
deleted 13y ago
[deleted]
aninhumer 13y ago
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.
- ghswa 13y ago
  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.
  - aninhumer 13y ago
    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.
platz 13y ago
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.
Peaker 13y ago
An effect system cannot express what transformers can. Consider the difference between StateT s Maybe and MaybeT (State s).

by ghswa 13y ago

gohrt 13y ago

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.

ghswa 13y ago
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 https://github.com/lrytz/efftp/wiki/Relative-Effects edit: That's effectively (sorry!) higher-order effects, behaving just as you'd expect.
Silhouette 13y ago
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.
- ghswa 13y ago
  Effect inference has already been done: http://research.microsoft.com/apps/mobile/showpage.aspx?page=/en-us/projects/koka/ http://research.microsoft.com/apps/mobile/showpage.aspx?page... I doubt we'll see anything like this in a mainstream language anytime soon.
  - Silhouette 13y ago
    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.
gizmo686 13y ago
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.
eli_gottlieb 13y ago
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.

deleted 13y ago

[deleted]

aninhumer 13y ago

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.

ghswa 13y ago
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.
- aninhumer 13y ago
  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.

platz 13y ago

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.

Peaker 13y ago

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