Introduction of GADT's for Unix.* and Lwt_unix.* types about lwt-node HOT 8 CLOSED

For the specific case of file permissions, it's superfluous to have async and sync ones – there is nothing about file permissions that is synchronous and asynchronous. Indeed, the types are identical in both Unix and Lwt_unix. IMO introducing these constructors for them hurts composability, and also misleads the user to think there is actually a difference.

So, I'd say to revert the second arguments to be file_perm (int) again.

from lwt-node.

@aantron I hear you, of the newly added constructors is file_descr the only one where there is a distinction? If so should I remove all other?

from lwt-node.

Maybe dir_handle needs the distinction, otherwise I think not. But you will only really know when trying to create the rest of the API around them.

from lwt-node.

Gotcha, I guess I should really just cross reference both Unix/Lwt_unix whenever new types are required by the functions from Unix/Lwt_unix in reason-node and check if their representations differ. Also I may just alias them just like Lwt did instead of GADT just for simplicity sake. Fun using GADT tho :)

from lwt-node.

That sounds like a good idea, though sometimes you may want an artificial distinction for the sake of your API. For example, even if Unix and Lwt_unix had the same representations of fds, you might still want to introduce a phantom type parameter in your API, or use two different types, if you want whether each fd is sync or async to be known to the type system.

from lwt-node.

@aantron when this is the case and the developer is using a function that has a file_descr argument, the type must be exposed for them to use right? Theres no way around that? Similar to what happened in the mkdir example

from lwt-node.

The type's name, or both name and definition? The type's existence (name) has to be exposed, yes, but you should be able to leave the definition abstract. For comparison, Unix.file_descr and Lwt_unix.file_descr are both abstract.

from lwt-node.

@aantron well if it's abstract wouldn't the value constructors not be accessible?

from lwt-node.