Runtime representation of eff is leaked
Closed this issue · 4 comments
Currently runtime representation of Eff is leaked to all libraries defining new Effs using FFI
If
- the representation was (or was assumed to be) some opaque structure
- and clients used only
require('output/Control.Monad.Eff.Unsafe/index.js').unsafePerformEffto run effect
for FFI-ing effectful code instead we could have done:
foreign import data ForiegnFff :: # Effect -> Type -> Type
toEff :: forall e a. ForiegnFff e a -> Eff e a
toEff = unsafeCoerce
libs will use ForiegnFff type for doing FFI and then toEff for actually using it.
This way representation could be changed (for example #29) without effecting users, (without major version change).
I think we should start making current representation opaque, and update all deps gradually.
If folks agree on it i could open pr to address this issue here.
I don't really see why this is a problem. Eff is just one possible representation of an effectful function, and if you want to use it, you need to know its representation. Adding a layer of indirection like this would be appropriate if we wanted Eff to be the only possible representation, but it's not.
like if we create an lib purescript-feff (for FFI Eff) Which is basically:
foreign import data FEff :: # Effect -> Type -> Type
foreign import unsafePerformFEff :: forall eff a. FEff eff a -> a
Then the Eff could even be implemented in PS, and it would be possible to update Eff internal representation without braking everything
Shall we close this? I agree with Phil's comment.