theduke (Sep 24 2022 at 18:06): theduke (Sep 24 2022 at 18:06):Just to make sure: there are no exceptions, so every function is either total or returns a Result / Task ?
Ayaz Hafiz (Sep 24 2022 at 18:06):Correct
theduke (Sep 24 2022 at 18:08):Great.
And... is there some syntax sugar for pipelines to forward to another argument than the first one? Like with a _ placeholder or similar?
Brendan Hansknecht (Sep 24 2022 at 18:08):caveat: Roc can panic. This happens for example when overflowing an integer type during addition. There is no way to catch/recover from this in Roc. It directly calls a platform function that decides how to proceed.
Brendan Hansknecht (Sep 24 2022 at 18:09):is there some syntax sugar for pipelines to forward to another argument than the first one?
No, you have to use a lambda |> \arg3 -> SomeFunc arg1 arg2 arg3
theduke (Sep 24 2022 at 18:14):Brendan Hansknecht said:
caveat: Roc can panic. This happens for example when overflowing an integer type during addition. There is no way to catch/recover from this in Roc. It directly calls a platform function that decides how to proceed.
That's a pretty big caveat.
So essentially the + etc operators are useless in most code, since you'd want to use addChecked or addWrap in most places.
Ayaz Hafiz (Sep 24 2022 at 18:15):well, if you are reasonably confident that + will not overflow, it could be a reasonable operator!
theduke (Sep 24 2022 at 18:16):Sure, but possibility for an abort in pretty much all code is not exactly why I'd use a functional language.
theduke (Sep 24 2022 at 18:17):Wouldn't a tradeoff like Rust does it be more sensible?
Panic in debug mode, but wrap in release mode?
Richard Feldman (Sep 24 2022 at 18:18):I thought about this, but after asking around, it seems like the worst nightmare stories around consequences of silently wrapping instead of aborting end up happening in unforeseen production edge cases that didn't come up in development
Richard Feldman (Sep 24 2022 at 18:21):so it seems like the most reasonable designs to me are:
+ always panics on integer overflow, like it does in Roc, Zig, and others+ silently upgrades to a bigger integer type on overflow, e.g. what Python does. I don't think the perf cost of this design is acceptable in Roc's case.+ always wraps, like in CI think what Rust and C++ do gives a false sense of security, and is more error prone than any of the 3 above designs
theduke (Sep 24 2022 at 18:26):I can get behind that reasoning, but honestly, in that case I'd be tempted to just not have the standard operators at all.
Which admittedly makes code much more awkward and unapproachable...
Richard Feldman (Sep 24 2022 at 18:27):yeah that would be a tough sell :big_smile:
Richard Feldman (Sep 24 2022 at 18:28):I figured this is the best default, and then in the rare cases where the performance is sensitive to arithmetic instructions being wrapped in a conditional, you can opt into Num.addWrap and the like
theduke (Sep 24 2022 at 18:28):What makes it really problematic is that with no exception mechanism, there probably isn't any way to recover from an overflow?
Brendan Hansknecht (Sep 24 2022 at 18:29):I think it is important to remember that in most code, wrapping is not the wanted functionality and would be a bug. The question is whether you want to continue executing when something would almost certainly be a bug. In systems that need to be correct, I would definitely have to go with a resounding no. If you continue executing you may end up doing something very incorrect. It is better to panic, let the platform cleanup (for example by returning a 500 if this is a web server), and then continue on.
Richard Feldman (Sep 24 2022 at 18:30):Num.addChecked is a way to recover
Richard Feldman (Sep 24 2022 at 18:30):basically + is saying "I don't expect this to overflow, but I wouldn't bet my life on it"
theduke (Sep 24 2022 at 18:30):Yeah, so essentially you have to either ban +-*/ from your code, or assume that your program can abort at any point.
I would hereby like to request a lint/compiler flag to forbid +-*/ ;)
Brendan Hansknecht (Sep 24 2022 at 18:30):there probably isn't any way to recover from an overflow?
The platform will be able to recover. The app will not be.
Richard Feldman (Sep 24 2022 at 18:31):whereas Num.addWrap is more like "I am absolutely certain this will not overflow" (or maybe you just want it to do wrapping overflow, e.g. in a hashing algorithm)
Richard Feldman (Sep 24 2022 at 18:31):computer programs in general can abort at any point
Richard Feldman (Sep 24 2022 at 18:31):e.g. due to stack overflows
Richard Feldman (Sep 24 2022 at 18:32):memory is finite
Richard Feldman (Sep 24 2022 at 18:33):if you want to absolutely guarantee that it won't happen, you have to get into things like proving there's no path through the program that could possibly exceed system resources, and run it on known hardware with multiple layers of hardware redundancy for all memory and CPU instructions, plus ample shielding from gamma rays
Richard Feldman (Sep 24 2022 at 18:33):and that's not Roc's target audience, so we have to draw the line for fault tolerance somewhere else :big_smile:
theduke (Sep 24 2022 at 18:34):Well, even then someone could just cut the power cable at any point. :)
theduke (Sep 24 2022 at 18:36):I think it just hurts my sensibilities a bit.
Not even Koka has an effect for overlow (I think).
Richard Feldman (Sep 24 2022 at 18:37):there are other things that panic: if you concatenate lists together until the resulting list can no longer fit in memory
theduke (Sep 24 2022 at 18:37):ps: do abilities work, or should I expect bugs?
Richard Feldman (Sep 24 2022 at 18:38):I don't know what Koka does there, but I'm quite sure it doesn't succeed :big_smile:
Richard Feldman (Sep 24 2022 at 18:38):so List.concat can fail, same with string concatenation
Richard Feldman (Sep 24 2022 at 18:40):also any language with recursive algebraic data types can have that same failure scenario, so it's not like you could even ban certain stdlib operations to rule it out - you'd have to disallow recursive sum types altogether
Richard Feldman (Sep 24 2022 at 18:41):I'd say abilities work but have seen very minimal battle testing compared to the rest of the language, so I would definitely expect bugs just due to lack of exposure
Richard Feldman (Sep 24 2022 at 18:44):these are great questions btw! I've thought a lot about them but haven't written them down... maybe worth a FAQ entry
theduke (Sep 24 2022 at 18:45):If you frame it that way, pretty much every operation can fail, because in a functional language chances are it might need to allocate.
But yeah I do get you need to make a tradeoff between usability and totality.
I'd actually love an effect based language that has effects for pretty much everything that can fail (and is under the control of the language, not the OS), but allows just globally ignoring a set of effects, depending on how high-level you want your code to be.
But I probably wouldn't want to see the compile times...
Arya Elfren (Sep 24 2022 at 22:44):The other thing zig does is give explicit wrapping operators so you choose the behaviour and then it never panics.
Richard Feldman (Sep 24 2022 at 22:47):yeah we could always have an operator like +? (for example) for Num.addChecked but I'm not sure the extra benefit there is worth the cost
Richard Feldman (Sep 24 2022 at 22:49):like Rust has add_checked and I just use that when I want addition with overflow checking, and I haven't hoped Rust would add an operator for it...even though Rust's threshold for adding new sugar for existing functionality is massively lower than Roc's
Last updated: Jul 26 2025 at 12:14 UTC