Sam Mohr (Dec 11 2024 at 02:37): Sam Mohr (Dec 11 2024 at 02:37):There's a good deal of Rust that is designed to flatten out pipelines, and I agree that I'm almost always happier with "flatter" code, a.k.a. code that allows more assignment of variables in preference
Sam Mohr (Dec 11 2024 at 02:38):One such feature is let-else, e.g.
let Some(value) = maybe_value else {
return "no-answer";
};
Some(value + 123 * 456)
It is a way to add if-style guards instead of
maybe_value
.map(|value| value + 123 * 456)
.unwrap_or("no-answer")
It means that the reader understands the intermediate steps in the program
Anthony Bullard (Dec 11 2024 at 02:41):I’d love some sort match or else assignment now that we have early returns
Sam Mohr (Dec 11 2024 at 02:44):I think we could consider extending the if-return feature to allow that!
Sam Mohr (Dec 11 2024 at 02:44):https://github.com/roc-lang/roc/issues/7105
Sam Mohr (Dec 11 2024 at 02:45):Something like
useResult = \res ->
Ok val = res else
return Err "whoops"
val.callFunc().nowThatItsValid()
8 messages were moved here from #ideas > Tags and dot syntax by Sam Mohr.
Anthony Bullard (Dec 11 2024 at 02:48):(deleted)
Sam Mohr (Dec 11 2024 at 02:49):I think you'd allow the following syntax:
val = 123, Ok 123 = Ok 123) Sam Mohr (Dec 11 2024 at 02:50):Made the example less confusing
Anthony Bullard (Dec 11 2024 at 02:51):Deleted my comment that became confusing :wink:
Sam Mohr (Dec 11 2024 at 02:51):Thanks
Anthony Bullard (Dec 11 2024 at 02:53):We have become braces-less Rust(or Gleam)
Sam Mohr (Dec 11 2024 at 02:53):I'm okay with this
Sam Mohr (Dec 11 2024 at 02:53):The look of gleam with performance close-ish to Rust
Anthony Bullard (Dec 11 2024 at 02:53):Not bad
Brendan Hansknecht (Dec 11 2024 at 02:54):and with platforms
Anthony Bullard (Dec 11 2024 at 02:54):I just wonder if we will now hit a wall with white space sensitivity over braces
Anthony Bullard (Dec 11 2024 at 02:54):Some people HATE WSS
Brendan Hansknecht (Dec 11 2024 at 02:54):It isn't an issue for languages like python, so should be fine
Anthony Bullard (Dec 11 2024 at 02:55):Good point
Anthony Bullard (Dec 11 2024 at 02:55):I love the concept and principles of ROC so the makeup doesn’t bother me too much
Anthony Bullard (Dec 11 2024 at 02:55):As long as it’s easy to learn and consistent
Sam Mohr (Dec 11 2024 at 02:56):I'm not afraid to admit I like a good coat of paint on my Ferrari
Anthony Bullard (Dec 11 2024 at 02:56):Breaking the functional contract or the strong locality would be a deal breaker for me
Sam Mohr (Dec 11 2024 at 02:56):I'm glad it doesn't bother you, then I can get my opinion in first!
Sam Mohr (Dec 11 2024 at 02:56):Locality is very important! Functional is a no brainer
Anthony Bullard (Dec 11 2024 at 02:56):Locality is huge. Big huge
Anthony Bullard (Dec 11 2024 at 02:57):My least favorite thing in a language is non-locality in imports
Sam Mohr (Dec 11 2024 at 02:57):In imports?
Anthony Bullard (Dec 11 2024 at 02:57):Yes
Sam Mohr (Dec 11 2024 at 02:58):Sorry, can you explain what you mean by that?
Anthony Bullard (Dec 11 2024 at 02:58):Like open in F#/OCaml
Sam Mohr (Dec 11 2024 at 02:58):Oh yeah, gross
Anthony Bullard (Dec 11 2024 at 02:58):Or #include in C/*++
Sam Mohr (Dec 11 2024 at 02:58):(sorry Ocaml fans!)
Anthony Bullard (Dec 11 2024 at 02:59):Even Elixir has this issue with use
Anthony Bullard (Dec 11 2024 at 03:00):It’s actually a concern I have with static dispatch
Anthony Bullard (Dec 11 2024 at 03:00):When there aren’t type annotations
Anthony Bullard (Dec 11 2024 at 03:00):It’s actually the biggest one
Anthony Bullard (Dec 11 2024 at 03:00):I’m all for parents-and-commas
Sam Mohr (Dec 11 2024 at 03:00):I'm thinking there may be value in automatically giving type annotations to all top-level defs
Anthony Bullard (Dec 11 2024 at 03:00):I think someone is working on that
Anthony Bullard (Dec 11 2024 at 03:01):Via formatter
Sam Mohr (Dec 11 2024 at 03:01):Well yes, they're adding a tool to do it, but I want to mandate it
Anthony Bullard (Dec 11 2024 at 03:01):I was gonna do it, but someone started a branch without assigning themselves
Sam Mohr (Dec 11 2024 at 03:01):Because without top-level defs having written type annotations, static dispatch could get really confusing
Anthony Bullard (Dec 11 2024 at 03:01):Ah, so you can write with none, but to build you have to format it first and get the annotations?
Anthony Bullard (Dec 11 2024 at 03:02):And I’m assuming can run/test without?
Sam Mohr (Dec 11 2024 at 03:03):Something like that
Anthony Bullard (Dec 11 2024 at 03:03):I’d like to see no-static dispatch Roc with parens and commas
Anthony Bullard (Dec 11 2024 at 03:04):It would basically be the language I made, but no function binding sugar and better lambda syntax
Sam Mohr (Dec 11 2024 at 03:04):I'm not sure how to deal with the formatter auto-type-annotating defs while you're writing them
Sam Mohr (Dec 11 2024 at 03:04):Hey, if you're looking for work to do, I don't think anyone is currently working on the parens issue
Sam Mohr (Dec 11 2024 at 03:04):If there even is a GitHub issue
Anthony Bullard (Dec 11 2024 at 03:04):I haven’t seen it
Anthony Bullard (Dec 11 2024 at 03:05):I have one bug I was gonna look at as soon as I finish my last day of AOC
Anthony Bullard (Dec 11 2024 at 03:05):Which is today :joy:
Sam Mohr (Dec 11 2024 at 03:05):Rest in peace, advent of code
Sam Mohr (Dec 11 2024 at 03:05):Christmas will never come :salute:
Anthony Bullard (Dec 11 2024 at 03:06):Too much time for someone with a job and a family and who likes to sleep
Anthony Bullard (Dec 11 2024 at 03:06):And contribute to Roc of course
Anthony Bullard (Dec 11 2024 at 03:07):Though I quite enjoy writing Roc over Rust
Sam Mohr (Dec 11 2024 at 03:07):Your family will understand that you have higher priorities
Anthony Bullard (Dec 11 2024 at 03:08):But I wonder what @Richard Feldman would think about doing static dispatch in two stages:
Anthony Bullard (Dec 11 2024 at 03:11):Phase 1 lands us at a place syntactically that is close to Gleam with WSS over braces. And if we time it with var and for could be an interesting point to decide if we want to try static dispatch for real (and lower the effort to do so)
Sam Mohr (Dec 11 2024 at 03:12):We talked about initially supporting both parens and spaces, we'd want to allow both, though I'm not sure how that would work
Richard Feldman (Dec 11 2024 at 04:51):I think doing it in two stages makes sense
Richard Feldman (Dec 11 2024 at 04:51):they can coexist because in practice nobody writes foo(bar, baz) today
Richard Feldman (Dec 11 2024 at 04:51):(it could parse as foo (bar, baz) but nobody would miss it if it didn't)
Richard Feldman (Dec 11 2024 at 04:53):Sam Mohr said:
There's a good deal of Rust that is designed to flatten out pipelines, and I agree that I'm almost always happier with "flatter" code, a.k.a. code that allows more assignment of variables in preference
One such feature islet-else, e.g.let Some(value) = maybe_value else { return "no-answer"; }; Some(value + 123 * 456)
I'm open to maybe doing some form of this, but I actually dislike the way Rust does it
Richard Feldman (Dec 11 2024 at 04:54):I think the thing that bothers me about it is that you find out it's a conditional after the fact
Richard Feldman (Dec 11 2024 at 04:54):like "doot doot doo going along assigning a thing to a WHOA else!!!"
Richard Feldman (Dec 11 2024 at 04:55):it might be too weird, but one idea could be:
if Ok foo = bar then
# use foo
else
return 42
just allow single = inside an if conditional
Richard Feldman (Dec 11 2024 at 04:56):I guess then you're still indenting one level, which is fewer than 2, but still more than 0
Richard Feldman (Dec 11 2024 at 04:56):(if I got my math right)
Sam Mohr (Dec 11 2024 at 04:56):That's the equivalent of if-let, but it still doesn't do the important part IMO, which is say "let's focus on the important case of when bar is Ok"
Sam Mohr (Dec 11 2024 at 04:57):Too bad try is already taken
Sam Mohr (Dec 11 2024 at 04:57):UNLESS
Richard Feldman (Dec 11 2024 at 04:57):that's an interesting one!
Sam Mohr (Dec 11 2024 at 04:57):We deprecate try when ? is ready and repurpose it
Sam Mohr (Dec 11 2024 at 04:58):try Ok x = val else
return "nope"
try Ok foo = bar else
return 42
# use foo
Or you pull from the Ruby book
Sam Mohr (Dec 11 2024 at 04:58):unless Ok foo = bar
return 42
# use foo
of note, this one doesn't need any different syntax, because of ?:
Sam Mohr said:
Something like
useResult = \res -> Ok val = res else return Err "whoops" val.callFunc().nowThatItsValid()
it can be:
useResult = \res ->
val = res.mapErr("whoops")?
val.callFunc().nowThatItsValid()
which I just realized has the same property of "the conditional part comes at the end" but for some reason it doesn't bother me when it's ?, unlike else :thinking:
Richard Feldman (Dec 11 2024 at 05:06):I don't really know why that's my reaction to it! :big_smile:
Sam Mohr (Dec 11 2024 at 05:10):Familiarity bias, perhaps
Sam Mohr (Dec 11 2024 at 05:11):I think your principle of "earlier info is better info" is great, but ? is an written language thing
Sam Mohr (Dec 11 2024 at 05:11):So we know it needs to follow different rules
Richard Feldman (Dec 11 2024 at 05:15):that makes a lot of sense!
Richard Feldman (Dec 11 2024 at 05:17):I think another thing that bugs me about the Rust style (which doesn't come up with ? either) is when you have like:
if let Ok(foo) = bar {
// ...
} else {
// ...
}
I think what bugs me about it is that it's semantically equivalent to using match with 2 branches, one of which is _ =>, except that it's more concise
Richard Feldman (Dec 11 2024 at 05:17):which in turn means that it rewards using _ => instead of exhaustive pattern matches
Richard Feldman (Dec 11 2024 at 05:17):and I dislike feeling torn between wanting conciseness and wanting exhaustive pattern matching
Richard Feldman (Dec 11 2024 at 05:18):I would rather it didn't offer me the conciseness option so I can always choose exhaustive pattern matching without having to debate tradeoffs in my head
Sam Mohr (Dec 11 2024 at 05:21):I agree that you should always prefer proper matches over if-let-else
Sam Mohr (Dec 11 2024 at 05:21):I respect Gleam's lack of if-else for this property
Sam Mohr (Dec 11 2024 at 05:22):I think we should do unless-return or try-else-return, but not if-let given that
Richard Feldman (Dec 11 2024 at 05:23):speaking of punctuation, could do something like this:
Ok foo = bar ??
return 42
# use foo
so it's kind of like with_default except lazily evaluated
Sam Mohr (Dec 11 2024 at 05:24):Are we still planning on doing ??, then?
Richard Feldman (Dec 11 2024 at 05:24):I don't think we have a concrete plan right now, but we certainly could
Richard Feldman (Dec 11 2024 at 05:25):actually I guess if it's with_default then it would just be:
val = result ??
return 42
# use foo
or even one line:
val = result ?? return 42
I think it made sense with
try readFile! "path" ? FileReadErr
?? []
Since we were trying to encourage good error handling with terseness
Sam Mohr (Dec 11 2024 at 05:26):I actually would love to keep these operators
Sam Mohr (Dec 11 2024 at 05:26):The one I think is more important is the map_err one
Sam Mohr (Dec 11 2024 at 05:27):Because people don't usually actually map_err in Rust, they just slap anyhow on everything, meaning they don't have a "call stack" of context
Richard Feldman (Dec 11 2024 at 05:27):yeah, I definitely prefer map_err over anyhow :thumbs_up:
Sam Mohr (Dec 11 2024 at 05:27):But since ? is staying as it normally works, maybe we can find a different operator for map_err
Richard Feldman (Dec 11 2024 at 05:27):I'm not sure how well an operator would work in method style though
Sam Mohr (Dec 11 2024 at 05:27):Well, the problem with Roc as it is today is that we have anyhow
Richard Feldman (Dec 11 2024 at 05:28):I guess really it's that an operator wouldn't work well with the ? suffix
Richard Feldman (Dec 11 2024 at 05:28):e.g. foo.bar().map_err(Baz)? works fine
Richard Feldman (Dec 11 2024 at 05:29):but (foo.bar() ?? Baz)? is awkward
Sam Mohr (Dec 11 2024 at 05:29):tryThreeThings! = \{} ->
try validateFile! "first.txt"
try validateFile! "second.txt"
try validateFile! "third.txt"
Ok {}
(well it probably wouldn't be ?? I guess, but the point is that an infix operator in the middle of a chain is weird)
Sam Mohr (Dec 11 2024 at 05:29):Which one failed?
Sam Mohr (Dec 11 2024 at 05:29):You're right that map_err is the solution here
Sam Mohr (Dec 11 2024 at 05:29):But it seems like not many people do that, so long as it type checks
Richard Feldman (Dec 11 2024 at 05:30):yeah I'm not sure if that's fixable though
Sam Mohr (Dec 11 2024 at 05:30):Though I don't have any evidence that a one-char operator would improve it... yep
Richard Feldman (Dec 11 2024 at 05:30):any solution is going to be strictly more work than zero work
Sam Mohr (Dec 11 2024 at 05:31):I can only hope that anonymous error unions make it easy enough
Sam Mohr (Dec 11 2024 at 05:31):map_err should be fine, though we probably also want map_err!
Sam Mohr (Dec 11 2024 at 05:32):I think without a map_err operator, we don't want ?? either for the reason you suggested
Richard Feldman (Dec 11 2024 at 05:33):well with_default comes up pretty often as the last thing you do
Richard Feldman (Dec 11 2024 at 05:33):as I recall several mainstream languages have exactly ?? as that operator
Richard Feldman (Dec 11 2024 at 05:33):except they use it for null instead of Result
Sam Mohr (Dec 11 2024 at 05:34):I'm okay with it, but we've decided for every other pipeline-adjacent operator to use words instead
Sam Mohr (Dec 11 2024 at 05:34):pass_to instead of |> or .>
Sam Mohr (Dec 11 2024 at 05:34):map_err instead of ?
Richard Feldman (Dec 11 2024 at 05:35):yeah, but an operator here seems like it has less downside because with_default is most common at the end of a series of chained calls, plus it makes it work much better with ?? return foo
Sam Mohr (Dec 11 2024 at 05:35):seems a little "uneven", but we have operators elsewhere
Richard Feldman (Dec 11 2024 at 05:35):because if it's a method, then it can't be lazily evaluated
Richard Feldman (Dec 11 2024 at 05:35):.with_default(return foo) doesn't work :big_smile:
Sam Mohr (Dec 11 2024 at 05:36):?? return Foo only works for results, right?
Richard Feldman (Dec 11 2024 at 05:36):whereas ?? can work like && and || are intended to in the future
Sam Mohr (Dec 11 2024 at 05:36):I think that's a little limiting
Richard Feldman (Dec 11 2024 at 05:36):yeah it would be like result ?? return Foo
Richard Feldman (Dec 11 2024 at 05:36):hm, how so?
Sam Mohr (Dec 11 2024 at 05:38):UserStatus : [
LoggedIn(User),
Inactive,
Deleted,
]
checkUserActivity : UserStatus -> Result _ _
checkUserActivity = \userStatus ->
unless LoggedIn user = userStatus
return Err NotLoggedIn
checkStatus(user)
Though you're right that we want short-circuiting for defaults!
Sam Mohr (Dec 11 2024 at 05:38):So I like that ?? is short-circuiting like && and || will be
Sam Mohr (Dec 11 2024 at 05:39):If you tell users that they should be converting everything to Results, then we get less-documented code
Richard Feldman (Dec 11 2024 at 05:39):ah I see what you mean, yeah it doesn't help in the situation where you want to early-return based on pattern matching on a non-Result :thumbs_up:
Sam Mohr (Dec 11 2024 at 05:39):Like in our canonicalization code where we use Result<Value, Type> because it's a convenient version of Either
Richard Feldman (Dec 11 2024 at 05:39):right haha
Sam Mohr (Dec 11 2024 at 05:40):Instead of doing Value | Type
Richard Feldman (Dec 11 2024 at 05:44):might be confusing, but we could have ?? work differently when used after a single-pattern match:
UserStatus : [
LoggedIn(User),
Inactive,
Deleted,
]
checkUserActivity : UserStatus -> Result _ _
checkUserActivity = \userStatus ->
LoggedIn user = userStatus ?? return Err NotLoggedIn
checkStatus(user)
although I don't know what it would mean if you didn't return after the ?? in that :laughing:
Richard Feldman (Dec 11 2024 at 05:45):I guess you'd be expected to provide an alternative user or something
Richard Feldman (Dec 11 2024 at 05:45):seems confusing
Richard Feldman (Dec 11 2024 at 05:46):anyway, I gotta go to bed, but it's an interesting topic!
Last updated: Jun 16 2026 at 16:19 UTC