How much should we have access to a library's internals to write an effect?

[Kleidukos]

It's actually two questions in one, because I feel like this should orient the design of libraries so that they are more "friendly" to 3rd-party effect systems.

There is this library and its main data structure (that I wish to have as part of my static effect) doesn't have its constructor exposed:

-- In the original library
module Queue
  ( EventQueue
  , Settings(..)
  , enqueue
  ) where

data EventQueue = EventQueue
	{ queue :: TQueue (Either () (IO ()))
	}

data Settings = …

enqueue 
  :: EventQueue
  -> IO ()
     -- ^ Action to insert in the work queue
  -> IO ()
enqueue wq = atomically . writeTQueue wq.queue . Right

-- In my effect

data Events :: Effect

type instance DispatchOf Events = Static WithSideEffects
newtype instance StaticRep Events = Events EventQueue

runEventQueue
  :: IOE :> es
  => Settings
  -> Eff (Events : es) a
  -> Eff es a
runEventQueue settings action = do
  queue <- liftIO $ newEventQueue settings
  evalStaticRep (Events queue) action

enqueue 
  :: (Events :> es1, IOE :> es2)
  => Eff es2 ()
     -- ^ Action to insert in the work queue
  -> Eff es1 ()
enqueue action = do
  Events queue <- getStaticRep @Events
  unsafeEff_ $ Events.enqueue queue (action) -- ⬅️ ❓

Question n°1: Should I ask for the library to open an Internal module and let me access its constructor so that I may re-implement enqueue?

Question n°2: Are there guidelines for library authors we can publish, an architectural style that they could follow so that the libraries are good clients for third-party effect systems?

[ocharles]

Sorry it doesn't quite answer your question, but why do you want to re-implement enqueue?

[ocharles]

Right, but are you saying you think you have to reimplement it, or you want to reimplement it? Because what you want seems possible through unlifting operations provided by effectful.

[Kleidukos]

yeah I don't want to re-implement it, but I feel like I have to.

[ocharles]

Are you OK with

enqueue 
  :: (Events :> es)
  => Eff es ()
     -- ^ Action to insert in the work queue
  -> Eff es ()

or do you really need es to differ?

[Kleidukos]

It's a good question, the original function accepts an arbitrary IO, so I must respect its ability to perform arbitrary IO, like database insertions, logging, etc. Does that make sense?

[arybczak]

I must respect its ability to perform arbitrary IO, like database insertions, logging, etc

The signature @ocharles provided doesn't prevent that. es will have appropriate constraints in the context where enqueue is called, i.e.

blah :: (IOE :> es, Events :> es) => Eff es ()
blah = enqueue $ liftIO (putStrLn "blah")

will work just fine.

Also, you most likely want this implementation:

enqueue :: Events :> es => Eff es () -> Eff es ()
enqueue = unsafeEff $ \es0 -> do
  Events queue <- getEnv @Events
  es <- cloneEnv es0
  Events.enqueue queue $ unEff action es

Because I'm pretty sure that actions are evaluated in a different thread than the one that calls enqueue.

This looks very similar to registerEff.