Using lawless typeclasses in d-p-extras

[qnikst]

Hi, Tim. This is more a question than a bug report, when I was inspecting d-p-extras code I saw a bug of lawless typeclasses. Those are used in order to be able to apply certain messages to a different types, however I'm curious if it's possible to remove amount of those.
For example:
Killable typeclass could be converted to

-- | Kill (instruct to exit) generic process, using 'kill' primitive.
killProc :: Resolvable p => p -> String -> Process ()
killProc r s = resolve r >>= traverse_ (flip kill $ s)

-- | Kill (instruct to exit) generic process, using 'exit' primitive.
exitProc :: (Resolvable p, Serializable m) => p -> m -> Process ()
exitProc r m = resolve r >>= traverse_ (flip exit $ m)

This will have the same effect as current instance as it's a catch-all instance and will not allow using non Resolvable types in it. If you want to allow a way to kill opaque (unresolvable) entities, you may want to use -XDefaultTypeSignatures and

instance Killable r where
   killProc :: Resovable r => r -> String -> Process ()
   killProc r s = resolve r >>= maybe (return ()) (flip kill $ s)
   ...

As I don't understand the all reasons behind all use typeclasses in d-p-* I'd like to know that, and if possible to make some work to remove amount of those, or introduce laws for them.

[hyperthunk]

This sounds like a very sensible improvement. What other instances should we look at? I'd be happy to tighten up the code where possible!!

[hyperthunk]

For an example of how these type classes are used, consider the Mailbox type in https://github.com/haskell-distributed/distributed-process-execution/blob/master/src/Control/Distributed/Process/Execution/Mailbox.hs. This hides the Pid from clients of the mailbox server, and the mailbox server client api calls require this type to communicate with the server, employing the compiler to ensure we don't send messages to one kind of gen_server (in this case, the mailbox) when in fact the process id points to other kind of server which won't understand the message (even if it understands the client protocol)...

[qnikst]

Synchronised seems redundant, is you want to have different locks it seems that it may better to use ADT there. If only one lock type is enough use use methods running in MonadCatch.
For other typeclass'es seems harder and I don't see a nice way to avoid them, so this why I created this issue, to understand the purpose for those and find best strategy there.

[hyperthunk]

Yeah, so Resolvable, Routable, and Killable (I couldn't find a neat way to encode Monitor-able) are there because the gen_server API (managed process, aka d-p-client-server) is designed so all managed process implementations can call it from the client side, but that's very imprecise so we advise in the docs and tutorials that you wrap the server process id in a newtype and use that to ensure compatibility between client and server. If you look at https://github.com/haskell-distributed/distributed-process-registry/blob/master/src/Control/Distributed/Process/Registry.hs, this is even more important, because the data wrapper that represents a server process is parameterised by the key and value types the server instance uses - it's a phantom type - which is the only guarantee you've got that the server and client will understand each other with respect to these types, since the server is genetically parameterised by k and v.

So Addressable and co, are really valuable for making it easier to interact with these kind of server handles. If we can ensure they're not lawless, it would be preferable though!

[hyperthunk]

By all means let's drop Sunchronized though, and make he other changes you proposed!

[hyperthunk]

Hi @qnikst - would you mind looking at #5 as a first stab? I haven't removed Synchronised there, but I will once we're happy I'm on the right path with these changes.

I also need to test the impact of them on libraries like supervisor and client-server, which I'll get to asap.

[hyperthunk]

Resolved in #5 - thanks for bringing this up @qnikst!