Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CCOption.bind and CCParse.bind have inconsistent parameter orders; should be unified? #466

Open
subservicer opened this issue Jan 1, 2025 · 3 comments

Comments

@subservicer
Copy link

subservicer commented Jan 1, 2025

Depending on this project's attitude toward breaking changes, it may be worth changing CCOption.bind : 'a option -> ('a -> 'b option) -> 'b option to align with the current type of CCParse.bind : ('a -> 'b CCParse.t) -> 'a CCParse.t -> 'b CCParse.t. I suggest this, rather than vice versa, to facilitate patterns like return x |> bind f |> bind g, following the general principle that a function's final argument should be the argument to which that function is least likely to be "partially" applied.

Making the types of all bind functions consistent throughout the library will make it easier to write functors that expect monads as well and help keep interfaces to CC modules predictable. As far as I can tell, these two are the only instances of bind throughout containers.

@c-cube
Copy link
Owner

c-cube commented Jan 1, 2025

I think that means that CCParse.bind is the wrong one, tbh. In general I use the infix operators anyway.

@subservicer
Copy link
Author

Thanks, quick reply!

Are you open to one of those functions changing, then? At least in principle?

I'm also curious what your reason for preferring 'a t -> ('a -> 'b t) -> 'b t is, over the other way round.

@c-cube
Copy link
Owner

c-cube commented Jan 3, 2025

I think I started this way because of Lwt.bind a long time ago. As I say, it's better to use let* these days :-).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants