5 ms·

As some of the Rust developers hang around here, a question: Result is the Either monad in Scala / Haskell? So IO functions return either a success wrapping a

As some of the Rust developers hang around here, a question: Result is the Either monad in Scala / Haskell? So IO functions return either a success wrapping a value, or a failure? This is great -- I'm a big fan of this style of error handling. However it seems that Rust doesn't have syntax for monads -- the equivalent of Haskell's do and Scala's for. This makes monads a bit of a PITA. Is there a plan to address this?

Ygg2 13y ago
As Rust ML lurker - there was some talk about using macros to fill in for this pain point, if I recall correctly. From what I've gathered do is dead and gone.
- lucian1900 13y ago
  For anyone not familiar with it, the `do` that was removed provided sugar for calling HOFs similar to Ruby blocks. Monadic do could be added in the future, backwards compatibly.
dbaupp 13y ago
People keep wanting monadic syntax (I'm one of them), but I believe the general suggestion is to do it via macros/syntax extensions. E.g. write something that desugars do! { bind x = foo(); let bar = baz(10); ret x + bar } into the equivalent of Haskell's do x <- foo let bar = baz 10 return $ x + bar Rust currently lacks higher-kinded types, so it would be hard to write functions that are generic over monads but the above would at least give some local reprieve. Also, note the `if_ok!` macro alluded to in the point about IO errors is giving the shortcircuiting behaviour of the Either monad (specific to Either, though). (NB. the macro probably can't be called `do` just yet, but we may remove that as a keyword. Maybe.)
- Ygg2 13y ago
  Wait, how don't macro need to take escaped sigils? Like range! takes range!('[' 0 , Inf ')' )? Is 'do' still a keyword? I remember it being removed, pretty much everywhere. I just assumed it was thrown away.
  - lucian1900 13y ago
    > Wait, how don't macro need to take escaped sigils? These are proper (hygienic) syntax macros, much like Scheme's syntax-rules. C's "macros" only work at the token level. > Is 'do' still a keyword? I believe it is still a reserved keyword, but not used anymore.
    - dbaupp 13y ago
      It appears to not be a reserved word at all: $ echo 'fn main() { let do = 1; }' | rustc - runs with just an unused variable warning (if it were reserved it would fail with "error: `do` is a reserved keyword").
      - brson 13y ago
        It probably should be reserved.
  - dbaupp 13y ago
    They need to take balanced braces/parens/brackets (i.e. only escaped if they are possibly unbalanced), so that Rust source can still be parsed without having to run the macro expander concurrently. And, it looks like do is no longer a keyword at all, I must've missed that part of the do-removal patch! So it is possible to call that macro do.
pcwalton 13y ago
"if_ok!" is designed to handle this. It's basically the equivalent of monadic do, but works better with the control flow structures of Rust.
- bcj 13y ago
  Is there a location in the docs that lists and describes the built-in macros in Rust? They don't appear to be findable using the stdlib search, and the Macros tutorial doesn't seem to talk about built-ins. Also, this post forced me to read the docs a bit more thoroughly and realize that I haven't been distinguishing between Option and Result. Thanks

Ygg2 13y ago

As Rust ML lurker - there was some talk about using macros to fill in for this pain point, if I recall correctly. From what I've gathered do is dead and gone.

lucian1900 13y ago
For anyone not familiar with it, the `do` that was removed provided sugar for calling HOFs similar to Ruby blocks. Monadic do could be added in the future, backwards compatibly.

dbaupp 13y ago

People keep wanting monadic syntax (I'm one of them), but I believe the general suggestion is to do it via macros/syntax extensions. E.g. write something that desugars do! { bind x = foo(); let bar = baz(10); ret x + bar } into the equivalent of Haskell's do x <- foo let bar = baz 10 return $ x + bar Rust currently lacks higher-kinded types, so it would be hard to write functions that are generic over monads but the above would at least give some local reprieve. Also, note the `if_ok!` macro alluded to in the point about IO errors is giving the shortcircuiting behaviour of the Either monad (specific to Either, though). (NB. the macro probably can't be called `do` just yet, but we may remove that as a keyword. Maybe.)

Ygg2 13y ago
Wait, how don't macro need to take escaped sigils? Like range! takes range!('[' 0 , Inf ')' )? Is 'do' still a keyword? I remember it being removed, pretty much everywhere. I just assumed it was thrown away.
- lucian1900 13y ago
  > Wait, how don't macro need to take escaped sigils? These are proper (hygienic) syntax macros, much like Scheme's syntax-rules. C's "macros" only work at the token level. > Is 'do' still a keyword? I believe it is still a reserved keyword, but not used anymore.
  - dbaupp 13y ago
    It appears to not be a reserved word at all: $ echo 'fn main() { let do = 1; }' | rustc - runs with just an unused variable warning (if it were reserved it would fail with "error: `do` is a reserved keyword").
    - brson 13y ago
      It probably should be reserved.
- dbaupp 13y ago
  They need to take balanced braces/parens/brackets (i.e. only escaped if they are possibly unbalanced), so that Rust source can still be parsed without having to run the macro expander concurrently. And, it looks like do is no longer a keyword at all, I must've missed that part of the do-removal patch! So it is possible to call that macro do.

pcwalton 13y ago

"if_ok!" is designed to handle this. It's basically the equivalent of monadic do, but works better with the control flow structures of Rust.

bcj 13y ago
Is there a location in the docs that lists and describes the built-in macros in Rust? They don't appear to be findable using the stdlib search, and the Macros tutorial doesn't seem to talk about built-ins. Also, this post forced me to read the docs a bit more thoroughly and realize that I haven't been distinguishing between Option and Result. Thanks