Rust and the Blub Paradox

Re:Rust and the Blub Paradox by pcwalton on Saturday January 23, 2016 @02:35PM (#10959686)

do is only really good if you use it for the whole function, or at least have some way to get the error out of the do block to the code that's supposed to handle it. But if break isn't allowed inside a do block, then if you need to break you have to split up your do blocks into blocks before the break and after the break. Now if there's an error thrown by one of the statements in one of those do blocks, then you have no straightforward way to propagate it out of the function. You would need to pattern match on the result of each do block and return the error if there was one--in other words, you would need to write try!

This is why I called try! monads for imperative languages: the early return that is expands to is the key to playing nice with imperative constructs like break and continue.

[ Parent | on HN ]

Re:Rust and the Blub Paradox by steveklabnik on Saturday January 23, 2016 @02:42PM (#10959721)

The usual implementation of the Either/Option monads already does this though:

    instance Monad Maybe where  
        return x = Just x  
        Nothing >>= f = Nothing  
        Just x >>= f  = f x  
        fail _ = Nothing

and

  instance (Error e) => Monad (Either e) where  
      return x = Right x   
      Right x >>= f = f x  
      Left err >>= f = Left err  
      fail msg = Left (strMsg msg)

The end result is still a value of that type. You get the short-circuting behavior as soon as you hit Nothing/Left.

[ Parent | on HN ]

Re:Rust and the Blub Paradox by pcwalton on Saturday January 23, 2016 @02:53PM (#10959764)

It only short-circuits to the end of the do block. But once you leave the do block the error isn't propagated anymore.

[ Parent | on HN ]

Re:Rust and the Blub Paradox by steveklabnik on Saturday January 23, 2016 @03:12PM (#10959856)

Right. Maybe this is because I tend to write small functions, but the amount of things that end in `Ok(())` especially with IO still makes me think it would be useful.

[ Parent | on HN ]

Re:Rust and the Blub Paradox by pka on Saturday January 23, 2016 @02:51PM (#10959757)

Can't break be simulated by something like MaybeT? And forWithBreakM :: [a] -> (a -> m (Maybe b)) -> m [b] that stops when f yields Nothing? (isn't this actually sequence . forM?)

[ Parent | on HN ]

Re:Rust and the Blub Paradox by pcwalton on Saturday January 23, 2016 @02:59PM (#10959797)

Yeah, there are transformations that we could apply to the code to make it work. But those transformations aren't trivial in the general case: how about breaking out of multiple loops or returns out of the function from inside loops? At some point, the transformations that we'd have to do would get so complex they'd hinder the programmer's mental model of what code will get generated. We'd also have to do a fair bit of work to make sure the optimizer can figure out what we're encoding so as to not lose performance.

[ Parent | on HN ]