4 ms·

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

by 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.

by gohrt 13y ago

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.