34 ms·

Author here. Thanks for the feedback! I agree that the do notation does look nice. The on thing that I like about the >> operator is that it's clear that you a

Author here. Thanks for the feedback! I agree that the do notation does look nice. The on thing that I like about the >> operator is that it's clear that you are performing a combining two functions. But to be honest I don't feel strongly either way. I definitely agree with your point on monads. I tried to keep this post more accessible, but I hope to go into a more technical post in the future on how we used monad transformers when writing these tests. We ended up using WriterT, ReaderT, LoggingT, EitherT for the "test components". Unfortunately the websocket library we used did not play well with this (it is callback based). And I also agree with your final points. Having said that, I had very low expectations in this area going in, and it actually turned out to be not nearly as bad as I expected.

chowells 11y ago
Callbacks are more or less handled by the continuation monad transformer, `ContT`, if you want to use it.
- fractalsea 11y ago
  Interesting. I think I will have to play around this before I get my head around it, but thanks for the suggestion.
tel 11y ago
At the risk of being a little pedantic, >> isn't combining two functions, e.g. Just () >> Nothing == Nothing Nothing >> Just () == Nothing It's perhaps viable to think of (m >> f) as modifying/continuing the m effect/computation using a continuation which is constantly the f effect. But that's about as close to "combining two functions" I can get it without specifically picking a monad that is a function. On the other hand, >=> is absolutely combining two functions. It's exactly (flip (.)) in a Kleisli category over some monad.
- fractalsea 11y ago
  By "combining" I just meant an operator that takes multiple functions and returns a new function based on those arguments. I guess these "functions" are a special case because they are constant monadic functions. Do you mean to say composition rather than combination when you are about >=>?
  - tel 11y ago
    Yeah, I'm happy to abide by this all when the caveats are specialized, but >=> is definitely and directly what's being appealed to. I meant combination just so as to generalize the idea of "composition". If you're willing to call Kleisli composition "composition" generally then I won't complain :)
- innguest 11y ago
  Yes, but let's be careful not to confuse beginners that thought they were on the path to understanding and then you come and say "it's not combining two functions". Well, it is combining two morphisms - that you can't deny. And most people use the shorthand word "function" to mean "any morphism" including type constructors. You may be technically correct but it is not incorrect for people trying to make sense of all these transformations, to say that >> combines two functions. These functions are picked up by the monadic context and executed in sequence.
  - tel 11y ago
    >> certainly never combines two functions! The closest you can come is to specialize the monad in context to ((->) e) and then talk about that kind of combination. The other way to go is to see >> as a special case of >=> wherein constant Kleisli functions are applied. I've got no problem with that now... Except now you're really talking about >=> and you may as well be specific?
    - innguest 11y ago
      You missed my point. Haskell beginners do not know we use the word "morphism" for the most generic "take an input, give an output" thing (the most generic map). That's why they call it "function". It's not wrong, just not specific enough. Does (>>) not combine two maps?
      - tel 11y ago
        It... doesn't. We appear to be talking past one another. How do you interpret (>>) :: Monad m => m a -> m b -> m b as combining two maps of any kind without either (a) specializing `m` to a function type or (b) considering it syntax sugar for a >> b ===> (const a >=> const b) ()
        innguest 11y ago
        > It... doesn't. It does! :) > How do you interpret (>>) :: Monad m => m a -> m b -> m b as combining two maps of any kind The answer is in your question. Is -> not an arrow? Isn't there one of those arrows pointing into and out of every m x in the signature above? (for the first and last m x, there could be arrows pointing in and out, respectively). That means they are maps. A morphism is any value that has arrows pointing to it (from other values) and out of it (to other values). Read my answer above as well. I am not debating your arguments. I know you know what you are talking about and you are right in what you're saying otherwise. What I am saying is in Haskell everything except Bottom is a categorical morphism, and you seem to be ignoring this concept, which is helpful for those who are trying to make sense of all this.
kungfooguru 11y ago
Do you plan to release any of this code? I'd love to see how the internals look for that.
- fractalsea 11y ago
  We currently do not have plans to release this code, mainly because it is very specific to our system. Having said that we are working on another large Haskell project, and we do have plans to open source a central component of it.

chowells 11y ago

Callbacks are more or less handled by the continuation monad transformer, `ContT`, if you want to use it.

fractalsea 11y ago
Interesting. I think I will have to play around this before I get my head around it, but thanks for the suggestion.

tel 11y ago

At the risk of being a little pedantic, >> isn't combining two functions, e.g. Just () >> Nothing == Nothing Nothing >> Just () == Nothing It's perhaps viable to think of (m >> f) as modifying/continuing the m effect/computation using a continuation which is constantly the f effect. But that's about as close to "combining two functions" I can get it without specifically picking a monad that is a function. On the other hand, >=> is absolutely combining two functions. It's exactly (flip (.)) in a Kleisli category over some monad.

fractalsea 11y ago
By "combining" I just meant an operator that takes multiple functions and returns a new function based on those arguments. I guess these "functions" are a special case because they are constant monadic functions. Do you mean to say composition rather than combination when you are about >=>?
- tel 11y ago
  Yeah, I'm happy to abide by this all when the caveats are specialized, but >=> is definitely and directly what's being appealed to. I meant combination just so as to generalize the idea of "composition". If you're willing to call Kleisli composition "composition" generally then I won't complain :)
innguest 11y ago
Yes, but let's be careful not to confuse beginners that thought they were on the path to understanding and then you come and say "it's not combining two functions". Well, it is combining two morphisms - that you can't deny. And most people use the shorthand word "function" to mean "any morphism" including type constructors. You may be technically correct but it is not incorrect for people trying to make sense of all these transformations, to say that >> combines two functions. These functions are picked up by the monadic context and executed in sequence.
- tel 11y ago
  >> certainly never combines two functions! The closest you can come is to specialize the monad in context to ((->) e) and then talk about that kind of combination. The other way to go is to see >> as a special case of >=> wherein constant Kleisli functions are applied. I've got no problem with that now... Except now you're really talking about >=> and you may as well be specific?
  - innguest 11y ago
    You missed my point. Haskell beginners do not know we use the word "morphism" for the most generic "take an input, give an output" thing (the most generic map). That's why they call it "function". It's not wrong, just not specific enough. Does (>>) not combine two maps?
    - tel 11y ago
      It... doesn't. We appear to be talking past one another. How do you interpret (>>) :: Monad m => m a -> m b -> m b as combining two maps of any kind without either (a) specializing `m` to a function type or (b) considering it syntax sugar for a >> b ===> (const a >=> const b) ()
      - innguest 11y ago
        > It... doesn't. It does! :) > How do you interpret (>>) :: Monad m => m a -> m b -> m b as combining two maps of any kind The answer is in your question. Is -> not an arrow? Isn't there one of those arrows pointing into and out of every m x in the signature above? (for the first and last m x, there could be arrows pointing in and out, respectively). That means they are maps. A morphism is any value that has arrows pointing to it (from other values) and out of it (to other values). Read my answer above as well. I am not debating your arguments. I know you know what you are talking about and you are right in what you're saying otherwise. What I am saying is in Haskell everything except Bottom is a categorical morphism, and you seem to be ignoring this concept, which is helpful for those who are trying to make sense of all this.

kungfooguru 11y ago

Do you plan to release any of this code? I'd love to see how the internals look for that.

fractalsea 11y ago
We currently do not have plans to release this code, mainly because it is very specific to our system. Having said that we are working on another large Haskell project, and we do have plans to open source a central component of it.