Chander Ramesh (Sep 07 2026 at 03:30): Chander Ramesh (Sep 07 2026 at 03:30):Apologies, I'm coming over from F# land, but it was very counter intuitive to me that this type of thing would be allowed:
(yes it was AI generated code that I'm reviewing). Is there a post I can find that explains why this decision was made? Also, is there a way to disable this or have the compiler warn about this?
Overall, really loving the language so far! Thanks to the whole team for all their hard work :)
Luke Boswell (Sep 07 2026 at 04:04):It only works for top-level statements i believe.
Luke Boswell (Sep 07 2026 at 04:05):I'm not really sure I understand why you would want to only permit things in a particular order?
Chander Ramesh (Sep 07 2026 at 05:45):It's just how I process files, top to bottom. It's awkward when reading something to be like, wait, what is this I've never even seen this before, only to find it's somewhere at the bottom. Maybe I'm too FSharp brained but I always thought that was a logical approach. Not a big deal, just curious. I'll just write my own lint rule for my project for my needs :)
Chander Ramesh (Sep 07 2026 at 05:46):Like on line 14 when you see complete, doesn't it make you pause and be like... what is complete? This is a purposefully trivial example ofc cuz it's literally on the next line.
Chander Ramesh (Sep 07 2026 at 05:50):oh wait, AI is informing me there is already a definition-before-use switch? lemme see if that solves my problem!
Chander Ramesh (Sep 07 2026 at 06:24):Nvm, as you mentioned it's only for top-level statements.
Chander Ramesh (Sep 07 2026 at 06:24):Can't compile flag that away; all good, will implement my own lint rule for now
Hannes (Sep 07 2026 at 10:52):I prefer the opposite, a top-down approach where you first define the main function which performs the high level business logic using a few smaller functions, then define those smaller functions further down to show the implementation details.
In a large project I think bottom-up approach becomes annoying, you'd have to read through every little utility function to fully understand the main function. If you name your functions well then you shouldn't need to look at the definition most of the time.
Hannes (Sep 07 2026 at 10:54):Although having said all that, most of the time I'm too python brained to remember I'm allowed to do that, maybe I should write the opposite linter to you :sweat_smile:
Richard Feldman (Sep 07 2026 at 12:09):@Chander Ramesh one concrete upside of this design is that Roc doesn't need let rec in general, or let and for mutually recursive functions - you can just define things that reference each other :smile:
Chander Ramesh (Sep 07 2026 at 16:24):Aaah I see. makes sense!
Krzysztof Skowronek (Sep 08 2026 at 14:50):I'm in similar position, reading the roc-ray examples makes me really scratch my head, sometimes the main program construction is in the middle of the file and I have to scroll around to find it
But I guess that's something you get used to
Though, order within file is very nice one you get used to it
Aurélien Geron (Sep 08 2026 at 21:03):I for one like the fact that I can define functions in my preferred order. For example, I can put all the important, user-facing stuff at the beginning, and keep the implementation details for later. I can also place related functions close to each other, without being constrained by dependencies. And as Richard mentioned, mutually recursive functions don't cause any headaches.
If you find out-of-order functions confusing, perhaps some tooling may help? Like a tool that would reorder a file based on dependencies? Or simply right click > go to definition ?
Aurélien Geron (Sep 08 2026 at 21:09):If we imposed dependency order, then a type module might be forced to look like this:
f = ...
g = ...
Foo::{}.{
h = ... # uses g
k : ... # declares k before using it in i
i = ... # uses k
}
j = ... # uses Foo.h
k = ...
The module type definition would be smack in the middle. Also, it might get weird if g depends on Foo.h.
Chander Ramesh (Sep 08 2026 at 21:18):Oh to be clear, I'm 100% ok with 'build your own tooling' being the solution here - that is acceptable, and I have :)
Program language designers have to think about 1000 use cases, and I just spend all day thinking about mine haha. Probably why I don't design languages! For my little use case, I'd never use mutual recursion or other things, so of course I didn't consider it, but when Richard said that, it made sense.
In my opinion, for your case @Aurélien Geron , if I saw that in a code review, I'd just say please move this to a different file or something (it's what F# makes me do today, after all). But not a big deal at all, esp in the age of AI, to build my own tooling to solve such a small nit.
Last updated: Sep 24 2026 at 15:59 UTC