Functions too eager?
Closed this issue · 9 comments
I'd like to understand how the FFI calls work in this library. From a quick look, it seems like calling something like return $ runFn4 ... as the implementation of something of type Eff would evaluate the right hand side too eagerly.
Ah yep, I can explain that no problem. It is totally broken. ;)
Node.FS.Async should be using something like mkEff $ \_ -> runFn4 ... as it does in Node.FS.Sync.
I meant to ask about that a long time ago actually, mkEff almost seems like something it'd be worth including in Control.Monad.Eff, thoughts?
I'd be a little concerned about putting it into Prelude, since it encourages unsafe practices, which are only fine if you know what you're doing. Morally, the only inhabitants of Unit -> a are constants.
Ah yes, good point. I'd meant to say Control.Monad.Eff.Unsafe actually, as we have that in the prelude already too for unsafeInterleaveEff.
Yeah I think the Unsafe submodule could be a good place for it. To be honest though, I don't see that many use cases. I guess the main one is like what you have here, where you want to capture some FFI function using FnX to avoid too many embedded JS strings.
I wonder if some types Eff1, Eff2 might help, which could be used to import foreign functions. That could be a nice job for an external library.
Absolutely, this kind of FFI usage really is the only thing I imagine it would ever be used for. Maybe it's not worth it, as it'd be simple enough to have as a private member for the cases where it's needed anyway... just thought I'd bring it up for discussion.
It's not urgent anyway, I just spotted this and was curious. We can chat about it whenever you're free on IRC.
Cool, I should be around more again from tomorrow I think. Will catch up with you then.
Probably worth keeping this open though as it is a bug at the moment.
Sounds good. I should be working on the book for one more week, then I'll be back onto compiler bugs.