Update on await syntax in Rust

Post by staticassertion » Tue, May 28, 2019, 6:45 PM UTC

kibwen wrote: post #119

staticassertion wrote: post #103

Earlier quoted context omitted.

Would the macro case be addressed by also supporting a prefix keyword? The post that states macros can't work does not cover this. From what I can tell: `foo.await!()` would just expand to `(await foo())`, and anyone could write their own `my_await!` macro that works similarly.

I as well think there could be promise in someday exploring that space, but for the moment my enthusiasm for hypothetical postfix macros (which have yet to ever be formally proposed) is somewhat dampened by the realization that `foo.bar.qux.qaz.await!()` would need to expand to `await { foo.bar.qux.qaz }`, which makes me consider how uncomfortable such macros would be to parse (the saving grace of "normal" macro call…

Post by steveklabnik » Tue, May 28, 2019, 6:52 PM UTC

iknowstuff wrote: post #122

steveklabnik wrote: post #109

Earlier quoted context omitted.

Yeah, I think the trick is that the theory and practice might be the same. And usually, it's the other way around; spreading it out makes it work, whereas it may not otherwise. For example: fn main() { let world = gives_string().split(" ").next(); println!("{:?}", world); } fn gives_string() -> String { String::from("hello world") } This will fail because the String is temporary, and we're trying to get a reference t…

This has surprised me on occasion. Shouldn't the compiler be smart enough to figure out how long to keep it around for, instead of failing to compile?

Post by tylerhou » Tue, May 28, 2019, 6:56 PM UTC

iknowstuff wrote: post #122

steveklabnik wrote: post #109

Earlier quoted context omitted.

Yeah, I think the trick is that the theory and practice might be the same. And usually, it's the other way around; spreading it out makes it work, whereas it may not otherwise. For example: fn main() { let world = gives_string().split(" ").next(); println!("{:?}", world); } fn gives_string() -> String { String::from("hello world") } This will fail because the String is temporary, and we're trying to get a reference t…

This has surprised me on occasion. Shouldn't the compiler be smart enough to figure out how long to keep it around for, instead of failing to compile?

Post by adwn » Tue, May 28, 2019, 7:05 PM UTC

jerf wrote: post #60

staticassertion wrote: post #55

Earlier quoted context omitted.

> Lazy vs strict semantics are completely orthogonal to the syntax [0] Alternatively, the syntax in Haskell just lends itself to lazy evaluation, and requires explicit annotation syntax to be strict. Contrasted with Python, which has a syntax that makes strict evaluation an easier default to express. If all languages can express, with some effort, the same exact semantics as any other language, then the only differen…

I'd submit the key difference in Haskell syntax is actually currying, not laziness. Haskell syntax privileges currying, and an executed function is just a curried function that has all of its parameters. By contrast, currying in languages with Algol-descended syntax always requires more rigamarole. It's possible, of course, in a lot of them, but it's harder than just a function call missing some of its arguments.

    def divide_by(a, b):
        return a / b

    divided_by_2 = divide_by(, 2)
    divide_5 = divide_by(5, )

    fn divide_by(a: f32, b: f32) -> f32 {
        a / b
    }
    // ...
    let divide_by_2 = divide_by(, 2.0);
    let divide_5 = divide_by(5.0, );

    let divide_by_2 = |a| divide_by(a, 2.0);

Post by uryga » Tue, May 28, 2019, 7:11 PM UTC

anchpop wrote: post #69

_v7gu wrote: post #52

Earlier quoted context omitted.

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right half_square = a |> square |> divide(_, 2)

I left the `()` because in some imperative languages there's a difference between `() -> a` and `a`, which makes `a.b` and `a.b()` different. In Haskell there's `>>>` and `&` in base, which I use all the time for this sort of workflow: find_half_square = square >>> (flip divide) 2 This creates a function which takes a value, performs `square`, then performs `(flip divide) 2`. It's written in pointfree style, which me…