{"action":"created","issue":{"url":"https://api.github.com/repos/agarwal/future/issues/13","labels_url":"https://api.github.com/repos/agarwal/future/issues/13/labels{/name}","comments_url":"https://api.github.com/repos/agarwal/future/issues/13/comments","events_url":"https://api.github.com/repos/agarwal/future/issues/13/events","html_url":"https://github.com/agarwal/future/issues/13","id":72363022,"number":13,"title":"functorize out core_kernel too?","user":{"login":"struktured","id":5060002,"avatar_url":"https://avatars.githubusercontent.com/u/5060002?v=3","gravatar_id":"","url":"https://api.github.com/users/struktured","html_url":"https://github.com/struktured","followers_url":"https://api.github.com/users/struktured/followers","following_url":"https://api.github.com/users/struktured/following{/other_user}","gists_url":"https://api.github.com/users/struktured/gists{/gist_id}","starred_url":"https://api.github.com/users/struktured/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/struktured/subscriptions","organizations_url":"https://api.github.com/users/struktured/orgs","repos_url":"https://api.github.com/users/struktured/repos","events_url":"https://api.github.com/users/struktured/events{/privacy}","received_events_url":"https://api.github.com/users/struktured/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-01T05:54:37Z","updated_at":"2015-05-01T10:42:53Z","closed_at":null,"body":"I know you intend on requiring core_kernel, but I feel like it wouldn't be terribly hard to remove core_kernel itself as strong dependency, and instead be an optional one just like lwt or async.\r\n\r\nAs far as I can tell, most of the dependency on core_kernel comes from the monad signatures ```Monad.S*```, ```Result```, and ```Or_error```.  The monad signatures can be directly copied without trepidation from core_kernel into future.\r\n\r\n ```Result``` is also fairly trivial and can be copied directly from core_kernel. Alternatively you could use an existing library if the signatures line up enough like [rresult](https://github.com/dbuenzli/rresult).\r\n\r\nNow, let's assume ```Or_error``` is truly worth being exposed in the future api ([is it?](https://github.com/agarwal/future/blob/master/src/future.ml#L31-L41\r\n) I don't know how important these ```Or_error.List``` functions are really). \r\n\r\nThen, instead of forcefully injecting ```Error.t``` with its sexp semantics and otherwise, we define a very abstract ```Error.S``` signature that core_kernel's ```Error.t``` adheres to, and provisional ones can be made for lwt which would not depend on core. Since ```'a Or_error.t = ('a, Error.t) Result.t```, this type doesn't have to syntactically change, which is nice.\r\n\r\nRegarding cfstream, which depends on core_kernel, you could use something such as gen for non core/async related implementations, and still cfstream otherwise. This is easy because both libraries are essentially swap in replacements of each other for most functions.\r\n\r\nI started doing some of the above changes in a fork but it's very experimental and doesn't compile at the moment. While I know this wasn't your goal with future, I wanted you to consider it once more before completely punting on the idea. I am willing to do most of the work involved if that's your biggest concern about it.\r\n\r\n- Cheers"},"comment":{"url":"https://api.github.com/repos/agarwal/future/issues/comments/98098258","html_url":"https://github.com/agarwal/future/issues/13#issuecomment-98098258","issue_url":"https://api.github.com/repos/agarwal/future/issues/13","id":98098258,"user":{"login":"ivg","id":2336698,"avatar_url":"https://avatars.githubusercontent.com/u/2336698?v=3","gravatar_id":"","url":"https://api.github.com/users/ivg","html_url":"https://github.com/ivg","followers_url":"https://api.github.com/users/ivg/followers","following_url":"https://api.github.com/users/ivg/following{/other_user}","gists_url":"https://api.github.com/users/ivg/gists{/gist_id}","starred_url":"https://api.github.com/users/ivg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ivg/subscriptions","organizations_url":"https://api.github.com/users/ivg/orgs","repos_url":"https://api.github.com/users/ivg/repos","events_url":"https://api.github.com/users/ivg/events{/privacy}","received_events_url":"https://api.github.com/users/ivg/received_events","type":"User","site_admin":false},"created_at":"2015-05-01T10:42:53Z","updated_at":"2015-05-01T10:42:53Z","body":"If you will copy `Result` you will get different one, that is incompatible with the core's one. That means, that a user who actually uses both future and core library will be unable to apply core functions on this `Result.t`. This will even introduce lots of problems, as Future's result constructors will hide Core's or vice verse. \r\nBut there are good news, by the way, very soon `Result.t` will [become](https://github.com/ocaml/ocaml/pull/147) a part of standard library."}}