Luke Boswell (Apr 29 2024 at 09:09): Luke Boswell (Apr 29 2024 at 09:09):I just wanted to share @Richard Feldman's new blog post Functional Semantics in Imperative Clothing in case anyone here has missed it. :heart: 
I've also shared the post on Hacker News and also to /r/programming, as these communities may find it an interesting read too.
I can't share it on lobste.rs as I'm not a member and I think this is a new domain. But if anyone else can share it I would be interested to know what that community think.
I've been using the ! syntax and updating some of my scripts and examples, and have found it nice to work with. There's still some work to do on error reporting, and getting a nice experience around that, but even now I think it's great (I might be a little biassed though :thinking:)
Keen to know what others think?
Richard Feldman (Apr 29 2024 at 11:03):by the way, at least for Hacker News, they penalize upvotes if you upvote after following a direct link (to prevent voting rings) so the best way to upvote is to click the "new" link in the upper left to see all the newest stories, and then find the link and upvote it there :big_smile:
Richard Feldman (Apr 29 2024 at 11:03):(you may have to go back a couple of pages to find it - HN gets a lot of new links!)
Richard Feldman (Apr 29 2024 at 11:54):front page of HN! :smiley:
Screenshot-2024-04-29-at-7.53.19AM.png
Georges Boris (Apr 29 2024 at 13:44):just read the article! I was a bit distant for a while so the ! syntax was a nice surprise. :) it does indeed clean things up a lot
I wonder if that in anyway changed features related to backpassing? (especially curious about record constructors for applicatives - I really liked those)
Richard Feldman (Apr 29 2024 at 14:10):no changes to record builders, although we separately have an idea for how to make the syntax for those a bit nicer too
Richard Feldman (Apr 29 2024 at 14:11):I hope that ! will mean we don't end up needing backpassing and can remove it, because the learning curve on backpassing hasn't been great and I'd like to make the language smaller if possible rather than supporting two ways to do the same thing :big_smile:
Georges Boris (Apr 29 2024 at 18:32):yeah! that was my fear as well, really hope can end up being small
I've been coding a lot of Gleam this last week and they have a syntax that is basically the same as backpassing. it was the bit that confused me more when trying the language (tho gleam is small and once you figure it out you can make sense of it...)
but the error messages end up getting thrown in weird places since backpassing is sugar but the error message doesnt recognize it, so it just explains the error as if you were using the function with callbacks.
I believe this would also be something to be mindful off, regardless of what syntax sugar is used... it would be amazing to have error messages pointing out at the actual user written code, and not to the desugarized version that the user is not seeing
Agus Zubiaga (Apr 29 2024 at 19:01):I believe our errors will only ever point at user written code since desugaring doesn't work at the level of the syntax. However, there's probably some type checking errors that can be enriched based on context about ! and other sugar.
Zellyn Hunter (Apr 29 2024 at 19:30):@Richard Feldman does your blog have an RSS/Atom feed? I was trying to figure out why I didn't see your post in NetNewsWire before I happened to notice it on Lobste.rs, and then couldn't find a feed, and vaguely remembered trying before…
Richard Feldman (Apr 29 2024 at 20:28):nope, I just put together a single static HTML page for this one post :laughing:
Richard Feldman (Apr 29 2024 at 20:28):I can add more things in the future haha
Zellyn Hunter (Apr 29 2024 at 20:32):re: backpassing being confusing — absolutely yes. For those of us coming from almost purely imperative languages like Go, the recursively-nested-this-is-purely-functional-because-its-returning-a-task-and-continuation-not-actually-doing-the-task pattern is already a bit mind-bending. Adding backpassing on top definitely made it more confusing. I could keep one or the other in my head for a while, but they tended to push each other out!
Richard Feldman (Apr 29 2024 at 20:35):yeah my hope is that with ! you don't need to understand as much of what's happening behind the scenes to be productive with it, so you can get comfortable with more aspects of the language...and then when you later learn more about what it's desugaring to, you can see parallels to things like Result that will hopefully make it easier to understand!
Zellyn Hunter (Apr 29 2024 at 20:56):btw, have y'all settled effect interpreters yet? I think seeing a description of how this works from the (presumably usually imperative) platform side would be clarifying.
Richard Feldman (Apr 29 2024 at 21:30):implementation work on them is still ongoing, but we have a design that as far as we know should work!
fast normaler roca (Sep 19 2024 at 08:26):Richard Feldman schrieb:
yeah my hope is that with
!you don't need to understand as much of what's happening behind the scenes to be productive with it, so you can get comfortable with more aspects of the language...and then when you later learn more about what it's desugaring to, […]
I have just read the article, and I have sympathy for the argument of keeping some details hidden from beginners. As a newbie in Roc (but experienced dev elsewhere) I wonder what would happen if Roc would silently imply the ! operator for each future automatically, such that it need not even be written-out in the source code. Of course, Roc would need another syntax providing access to the future without actually executing it. This additional syntax would be something for experts, and not relevant for most beginners. (I am thinking of putting the future between braces, or sth. similar, thereby indicating that a runnable function is contained within sth. that requires unpacking to free the beast. Hope you know what I mean.)
What do you think: would that be another improvement, or rather too much obfuscation?
Anton (Sep 20 2024 at 08:09):I wonder what would happen if Roc would silently imply the
!operator for each future automatically, such that it need not even be written-out in the source code.
We discussed this, the conversation diverged into multiple threads but I think we agreed that we wanted to keep the visual indicator for functions that executed effects because it's beneficial to be able to instantly see which functions execute effects.
Last updated: Jul 06 2025 at 12:14 UTC