function equivalent of "do" notation

[sanctuary-js]

function equivalent of "do" notation

[buzzdecafe]

They're all specific cases of a more general Semigroupoid idea.

I recall you and @scott-christopher discussing that in the gitter room. i may take a whack at unifying our many composers into one.

Which raises the thought: A good name for a javascript composition lib would be Bach.js

[benperez]

Oh, duh. 🐐

The only limitation I see here is that this form of do notation only really allows you to feed through a single monadic value. You lose the ability to bind different variables to different monadic values in the same do expression like the following example:

foo :: Maybe String  
foo = do  
    x <- Just 3  
    y <- Just "!"  
    Just (show x ++ y)

[buzzdecafe]

wow, that is nice sugar. FWIW, I think $do is fine

[davidchambers]

wow, that is nice sugar.

I think so too! Shall I open this for discussion on the Ramda issue tracker? The function could be defined there instead. :)

[buzzdecafe]

your call. looks pretty interesting to me.

Can't you also do this:

// $do :: Monad m => [(a -> m b), (b -> m c), ..., (y -> m z)] -> m a -> m z
const $do = R.apply(R.pipe, R.map(R.chain));

?

It also seems like there is a way to write this with ap, but don't have time to prove that right now

[davidchambers]

The types don't line up in your definition, @buzzdecafe. You're fully applying (ahem) R.apply (which takes two arguments).

[benperez]

Why isn't do a valid identifier?

[davidchambers]

do is a keyword: do...while.

[buzzdecafe]

yep, i was reading apply like compose for some reason

[davidchambers]

The only limitation I see here is that this form of do notation only really allows you to feed through a single monadic value.

True. R.compose and R.pipe share this limitation, of course.

[benperez]

R.compose and R.pipe share this limitation, of course.

I don't really see how that relates. I think you might be able to come up with a way to bind different variables but I'm guessing it would be pretty hacky.

I think this is cool for the single pipeline case though!

[buzzdecafe]

I think you might be able to come up with a way to bind different variables but I'm guessing it would be pretty hacky.

indeed. I was trying to come up with some way to do that, but all i could come up with could only generously be called "hacky"

[joneshf]

Does do go by other names?

The name you're looking for is Kleisli: https://en.wikipedia.org/wiki/Kleisli_category

What you've Greenspun'd is exactly Kleisli composition. :)

See also: >=> and <=<

[davidchambers]

The name you're looking for is Kleisli

It sounds as though Ramda needs more composition functions. R.composeK and R.pipeK, anyone?

[buzzdecafe]

😱

[joneshf]

Sorry, I didn't actually look close enough. $do isn't entirely kleisli composition. If you have:

// kleisli : Chain m =>  [a -> m b, b -> m c, ..., y -> m z] -> a -> m z

Then yes.

Also, note that you don't actually need the full power of Monad for this.

[joneshf]

It sounds as though Ramda needs more composition functions. R.composeK and R.pipeK, anyone?

No, it definitely needs less (ideally one). They're all specific cases of a more general Semigroupoid idea.

[davidchambers]

@joneshf, do you think such a function should return a -> m z rather than m a -> m z?

I'm having a bit of trouble seeing how something of the shape

R.pipe(
  S.Just,
  R.chain(f),
  R.chain(g),
  R.chain(h),
  R.chain(i),
  R.chain(j)
);

can be rewritten as a pipeline where every function in the pipeline is a partially applied R.chain.

[joneshf]

@joneshf, do you think such a function should return a -> m z rather than m a -> m z?

I was just nitpicking, and looking more closely at the haskell stuff.

They're equivalent, so either way is fine, since (f >=> g) x = f x >>= g and x >>= f = (id >=> f) x. So choose either one and you can provide the other easily.

I'm having a bit of trouble seeing how something of the shape
...
can be rewritten as a pipeline where every function in the pipeline is a partially applied R.chain.

Hmm, I think I'm having a brain fart here, or I'm not understanding the question.

[davidchambers]

They're equivalent, so […] choose either one and you can provide the other easily.

That makes sense. :)

I think I'm having a brain fart here, or I'm not understanding the question.

I didn't see at the time how to return a -> m z rather than m a -> m z. I do now. The implementation is a bit more involved, since one must apply R.chain to all the arguments but the first:

// $do :: Chain m => [(a -> m b), (b -> m c), ..., (y -> m z)] -> a -> m z
const $do = R.pipe(R.converge(R.prepend,
                              R.head,
                              R.pipe(R.tail, R.map(R.chain))),
                   R.apply(R.pipe));

[Ramda's various composition functions and the proposed Kleisli composition functions are] all specific cases of a more general Semigroupoid idea.

I'm intrigued by the possibility of a composition function which can perform Kleisli composition as well as "regular" function composition. I've no idea how this is possible. :)

[joneshf]

Thinking about it now, I think the only way to make it happen is to wrap the monadic function in a Kleisli type.

[joneshf]

Also, if it wasn't clear from the signature Kleisli == ReaderT, and a -> b == ReaderT Identity a b. So that's why I feel these can be unified. But I think without a compiler implicitly passing around things and wrapping/unwrapping, it'd end up being a less than optimal api.

[CrossEye]

But I think without a compiler implicitly passing around things and wrapping/unwrapping, it'd end up being a less than optimal api.

That's often where the rubber meets the road with JS libs. There a lot of 'almost's and 'if only's floating around, usually having to do with its type system.

[joneshf]

Thinking about it more, you'd run into the same api issues in haskell. And the ways around it are just as suboptimal, but for different reasons. I guess I just want too much.

[davidchambers]

ramda/ramda#1212 added a variadic version of the proposed $do function as R.pipeK.

[gabejohnson]

@davidchambers, any interest in revisiting this now that Sanctuary is no longer dependent on Ramda?

[davidchambers]

Absolutely! Let's open a new issue: pipeK is more limited than Haskell's do notation because it doesn't provide access to the results of all previous computations. Would you mind opening an issue for pipeK, @gabejohnson?

[gabejohnson]

I can do that.

I've also been looking at arrows and categories. Seems like something that would be useful to add to the spec.

[gabejohnson]

Looks like there's already an issue for it fantasyland/fantasy-land#208

[gabejohnson]

See #380