These are chat archives for rust-lang/rust

12th
May 2016
nishidy
@nishidy
May 12 2016 00:01
i was editing the last line but it just comes to my mind that they are kind of similar in theory
Sean Perry
@shaleh
May 12 2016 01:08
correct. Go returns tuples (value, maybe_err) which is like Haskell's Either or Rust's Result
Haskell has useful sugar to handle them.
Go style uses 'if result, err := func(); err != nil'
Rust style use 'if let Ok(result) = func() { }'
or 'match func() { Ok(result) => { ... }, Err(e) => {...} }'
Sean Perry
@shaleh
May 12 2016 01:13
in Rust when you call 'foo.unwrap()' and foo is an error you get a panic. You cannot check it. To check the value of foo you can either match it, use the if/let syntax, or use something like foo.is_ok()
shaleh @shaleh just remembered that markup works here....
Carlos Gratacos
@cjgratacos
May 12 2016 01:14
@shaleh nice explanation
Sean Perry
@shaleh
May 12 2016 01:15
@cjgratacos thank you
I personally prefer the Haskell sugar. foo >> bar >> baz or foo >>= bar >>= baz is quite handy and keeps the 'noise' of error handling down. Kind of like exception handling in Python or other languages.
Go IMHO is a little too low level in this case. Rust with useful types like Option and Result along with match is nicer.
Vladimir Matveev
@netvl
May 12 2016 07:41
@nishidy Option and Result both have monad and monad-plus combinators: and_then(), or(), or_else() for example
so there is something like >>=/>>, although it is kinda noisy
if let Some(x) = opt is a nice alternative when you need side effects
Daniel Collin
@emoon
May 12 2016 07:44
you can also do foo.map(|v| { do something here });
Bunch of different ways to do this with unwrap_or etc https://doc.rust-lang.org/std/option/enum.Option.html
fstuess
@fstuess
May 12 2016 07:59
Maybe the try! macro is worth mentioning.
Vladimir Matveev
@netvl
May 12 2016 08:03
yes, though it only works with Result
Zakarum
@omni-viral
May 12 2016 08:11
There is try_opt! in some crate. Which is the same try! but for Option
Don't remember the name of the crate... maybe it "try_opt"
Vladimir Matveev
@netvl
May 12 2016 08:12
it is also possible for ? to be extended to handle other types than Result in the future. after all, its RFC initially described the trait-based approach
nishidy
@nishidy
May 12 2016 09:20
Great tips, thanks. In terms of it, rust is similar to Scala, too...
Zakarum
@omni-viral
May 12 2016 12:59
I'm not sure if this new syntactic sugar have more pros than cons
Sean Perry
@shaleh
May 12 2016 14:52
I find the and_thengroup to be quite noisy. Too much like the Javascript snarl.
fstuess
@fstuess
May 12 2016 16:26
@SCareAngel : matter of taste i think. For my narrowed mind sometimes all the conciseness of FP language sugar is scary and i cannot understand until reading it at least 8 times and sometimes it's so perfectly elegant. See what the ocaml folks does with ocsigen. Looking at GO, most of it is very simple and explicit and you can read the whole block and understand it immediately, but (for me, pls no lang war, all languages are good at points) it feels like writing basic back in the early 90ies here and there. Still i want to say that the agility at which rust is developing and the surrounding community is really fantastic and maybe there is a solution to get the haskell >>= into it and still have and_then() and stuff. There are many people doing magic around :-)
LeonineKing1199
@LeonineKing1199
May 12 2016 16:27
I think conciseness is the one thing that's not wrong with FP, hey-oh!
fstuess
@fstuess
May 12 2016 17:12
+1
Sean Perry
@shaleh
May 12 2016 17:13
There is a balance between clarity and concise.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:16
There certainly is. If anything, the one thing holding back FP is its inaccessible terminology.
Sean Perry
@shaleh
May 12 2016 17:16

foo >>= bar x >>= baz y is both concise and clear once you know what >>= means.
foo.and_then(|x| blah).and_then(|y| blarg) is denser. The reader does not have whitespace and symbols to make it easier and faster to comprehend.
Sure some new lines help

foo.and_then(|x| blah)
        .and_then(|y| blarg)

But when it comes time to refactor the dev has to rewrite the lambdas, change out the Monad helper functions, etc.

@LeonineKing1199 totally agree. I am using Monad because I trust people have seen it. But I am not spouting out isopolymertantrimetric gobbledy gook :-)
LeonineKing1199
@LeonineKing1199
May 12 2016 17:18
Honestly, I'm not sure if this is correct or not but I'm interpreting a lot of the stuff as, "this is a class the encapsulates a value. It has methods that takes functions as arguments and calls those functions with the encapsulated value."
Sean Perry
@shaleh
May 12 2016 17:19
Almost there.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:20
Phew.
Sean Perry
@shaleh
May 12 2016 17:20
class is a loaded word.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:25
Out of curiosity though (I really am trying to learn more FP), what was missing from my interpretation? Was it the lack of "lifting" a value into being a monad?
Sean Perry
@shaleh
May 12 2016 17:25
class just means different things to different people is all.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:25
Ah, I see.
I'm trying to get better about implementing the functional compositions in imperative ways. Mostly just because it's fun. Like, I wanna get good enough at CUDA that I can do some cool stuff with their fancy iterators :)
Sean Perry
@shaleh
May 12 2016 17:27

In Haskell,

foo >>= bar x >>= baz y

can also be written in this format (which is really sugar for the above)

do
    v <- foo
    z <- bax x v
    baz y z

Which looks very imperative

Similar to how in Rust the foo.and_then()...... can be broken out into match syntax.
Just imagine a let in front of those variable assignments
In C++ a class means a struct containing data coupled with functions that act on that data. In FP class is often used like trait is in Rust.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:31
Where is describes more of an interface?
Sean Perry
@shaleh
May 12 2016 17:31
which is mostly like an abstract base class from the C++ OO mindset
@LeonineKing1199 right
LeonineKing1199
@LeonineKing1199
May 12 2016 17:32
Yeah, that's what I interpreted that to mean.
Hence why 'class' is a loaded term...
Sean Perry
@shaleh
May 12 2016 17:33
Right. If you look at the binary output a C++ class instance is a struct with an array or similar of pointers to functions.
LeonineKing1199
@LeonineKing1199
May 12 2016 17:34

That would be the most readable C ever XD

I had to ask if it was weird to dereference the this pointer and use operators on it. I had overloaded the operator[] and I was implementing the at function which is operator[] with bounds checking and I wrote (*this)[idx] and for some reason, that just felt so wrong to me...

Sean Perry
@shaleh
May 12 2016 17:34
read up on the idea of 'algebraic types' and you will be heading down the path of understanding modern FP design.
nah, using this is expected when operating on class local bits. I much prefer the explicit self of Python, Rust, and others.
type Result = Ok value | Err string
I kind of made an enum there, right? But both Ok and Err take a value too.