Live data from Hacker News

Weird Expressions in Rust

wakunguma.com

151–155 of 155 posts

Re: Weird Expressions in Rust

#151

Earlier quoted context omitted.

Steve, I know you're an authority on the language but you've dismissed the point being made here without engaging with it. Return is a statement in the minds of most programmers, but an expression in the language. That was a very pragmatic decision that required an unintuitive implementation. As a result, we've got this post full of code that is valid to the compiler but doesn't make a lick of sense to most programme…

> Return is a statement in the minds of most programmers I would take issue with this, sure, for a lot of people, they may be bringing assumptions over from languages where assignment is a statement. That doesn't make them correct. > required an unintuitive implementation To some people, sure. To others, it is not unintuitive. It's very regular, and people who get used to "everything is an expression" languages tend…

> ...people who get used to "everything is an expression" languages tend to prefer it, I've found.

This feels awkward as my mental model is that in "everything is an expression" languages you simply DO NOT offer "return" (and, if you do, it must be mapped to bottom and do something insane like throw an exception... but, like, if you are really used to using such a language, you'd never let yourself type a "return", as the entire concept feels icky and wrong in such a language).

Re: Weird Expressions in Rust

#152

Earlier quoted context omitted.

What Rust's syntax really reminds me of is Algol 68, or BLISS, both of them being these old procedural languages where everything is an expression. The "loop { ... break expr; ... }" thing reminds me of BLISS's "exitloop expr" construct.

There's so many programming languages (low barrier to create) that there's a ton of overlap and evolutionary changes/similarities between them. I was thinking of perl's "do { x } while foo" style constructs in this particular case. I am incredibly amused that I got downvoted to -1 for mentioning perl though. People here are Weird .

Oh, sorry, I didn't downvote you. Just gave you an upvote.

Re: Weird Expressions in Rust

#153

Earlier quoted context omitted.

> In Haskell or ML or whatever `emptyList` would be given a polymorphic type, `List a` or `'a list`. That alone would not work. Think about it: `List a` means "A list that contains values of type `a` and `a` can be any type whatsoever". Now imagine you combine that list with a list of integers. That obviously cannot work, since `(++) :: [a] -> [a] -> [a]` as you see, the types must align. The way Haskell fixes that i…

You are misreading the quantification, a value l of type List a means that for all type a, the element of the list has type a. In other words, this is an universal quantification whereas your interpretation is an existential quantification. This is obviously only possible if the list itself has no elements, and indeed a simple proof is that the statement above is valid for the empty type: all elements of a list of ty…

> this is an universal quantification whereas your interpretation is an existential quantification

Indeed, I stand corrected. Interesting! I'll look into that a bit more, thank you.

Re: Weird Expressions in Rust

#154
post #151

Earlier quoted context omitted.

> Return is a statement in the minds of most programmers I would take issue with this, sure, for a lot of people, they may be bringing assumptions over from languages where assignment is a statement. That doesn't make them correct. > required an unintuitive implementation To some people, sure. To others, it is not unintuitive. It's very regular, and people who get used to "everything is an expression" languages tend…

> ...people who get used to "everything is an expression" languages tend to prefer it, I've found. This feels awkward as my mental model is that in "everything is an expression" languages you simply DO NOT offer "return" (and, if you do, it must be mapped to bottom and do something insane like throw an exception... but, like, if you are really used to using such a language, you'd never let yourself type a "return", a…

Ruby is an "everything is an expression" language and it has return, and idiomatically it's used identically to Rust: for early returns.

It is of course not statically typed.

Re: Weird Expressions in Rust

#155
post #151

Earlier quoted context omitted.

> ...people who get used to "everything is an expression" languages tend to prefer it, I've found. This feels awkward as my mental model is that in "everything is an expression" languages you simply DO NOT offer "return" (and, if you do, it must be mapped to bottom and do something insane like throw an exception... but, like, if you are really used to using such a language, you'd never let yourself type a "return", a…

Ruby is an "everything is an expression" language and it has return, and idiomatically it's used identically to Rust: for early returns. It is of course not statically typed.

Ruby is complex as it does the thing I said: 1) return is bottom, and so you can't have return "statement"--most people call it a statement even though it is a "void value expression"... but, like, once the type of an expression becomes sufficiently encoded in the syntax, how is it not a statement?--in a context where an expression would go; and 2) it isn't even the same thing as what Rust is doing, as it is a non-local construct that is effectively throwing an internal form of exception, allowing you to "return" from a function far up the call stack, and so it's rules are a bit more regular and useful: Ruby is coming at the notion of almost everything is an expression so as to allow expressions that look like statements, and that's a very different motivation than the syntax we are seeing here in Rust.
Post reply on HN