purescript / purescript-effect Goto Github PK

Great work in getting so many libraries updated for 0.12.

The link in Effect.purs to

See [Handling Native Effects with the Effect Monad](http://www.purescript.org/learn/eff/)

is broken. I imagine because no-one's yet had time to do the documentation. But I think it's quite important to do this quite soon after the release - it's a major change.

Hi, looking at the example on the README:

// Counter.js
exports.incrCounter = function() {
  if (!window.globalCounter) {
    window.globalCounter = 0;
  }
  return ++window.globalCounter;
}

and then looking at the implementation of pure, shouldn't incrCounter be thunked?:

// Counter.js
exports.incrCounter = function() {
  return function() {
    if (!window.globalCounter) {
      window.globalCounter = 0;
    }
    return ++window.globalCounter;
  }
}

I'm trying to figure out how Effect works, so my apologies in advance if this It's just me not understanding properly.

The file mentioned in the title links to http://www.purescript.org/learn/eff/. That links returns a 404.

liftEffect is commonly used, I believe it would be better to re-export it from Effect.Class in Effect module, instead of having to type this:

import Effect (Effect)
import Effect.Class (liftEffect)

From the docs:

EffectFn{N} means, a curried function which accepts N arguments and performs some effects. The first type argument is the row of effects, which works exactly the same way as in Effect. The last type argument is the return type. All other arguments are the actual function's arguments.

This seems like it was copied over from Eff without regard to the removal of effect rows.

Furthermore, the number of arguments seems somehow incorrect:

data EffectFn1 :: Type -> Type -> Type

I would expect one fewer type argument per EffectFn function. The function above takes two arguments, not one.

While this could be addressed by a documentation change, this leaves the EffectFns not matching their corresponding Fns from purescript-functions.

Due to strict evaluation, if a function takes an Effect a as an argument, it's often desirable to defer evaluation under a lambda literal, particularly if there are non-trivial let bindings.

example = doThis do
  let foo = ...
  let bar = ...
  doThat foo bar

This will likely evaluate foo/bar in the process of allocating the effect. If there was a Lazy instance, one could do:

example = doThis $ defer \_ -> do
  let foo = ...
  let bar = ...
  doThat foo bar

Definitely deferring evaluation of foo/bar until the effect is actually invoked. We can't implement an instance for Lazy (control depends on effect), and this module doesn't export this as a primitive so the implementation would need to rely on unsafeCoerce.

Proposed implementation:

foreign import defer :: forall a. (Unit -> Effect a) -> Effect a

exports.defer = function(k) {
  return function() {
    return k()();
  };
};

There has been discussion a few times of whether Data, Control, and so on is actually a useful way of grouping stuff, plus ideas about flattening the namespace a bit to match namespace with library names to try and prevent namespace collisions.

Since this is a new library, and will be introduced into the usage of the core libraries soon, it might be time to consider making the change now? Also relevant comment here: purescript/purescript-exceptions#26 (comment)

Is there any interest in porting purescript-deprecated/purescript-eff#31 here?