Anton (Feb 28 2023 at 12:17): Anton (Feb 28 2023 at 12:17):I read about #4431 in the other topic and I have some concerns about it.
For context; with #4431 we want roc format to reorder defs to match dependency order. So if the user writes:
x = y + 1
y = 3
We want the formatter to re-write it to
y = 3
x = y + 1
This case looks trivial of course but as things currently are implemented we would need to call canonicalization functions to achieve this. My concerns are:
Anton (Feb 28 2023 at 12:28):Relatedly, the compiler currently silently does the re-ordering of:
x = y + 1
y = 3
To
y = 3
x = y + 1
I think we should error on out-of-order defs because they are inherently hard to read and confusing. I expect we can then remove the code that does this analysis and the auto-fixing. Code that does not exist can not fail, complicate things or have a performance cost :)
Richard Feldman (Feb 28 2023 at 13:40):I expect out-of-order defs to come up rarely so the upside seems really small to me.
that's an interesting point! Maybe a good next step would be to introduce the error for out-of-order and then see how often it comes up
Richard Feldman (Feb 28 2023 at 13:40):then we'd be able to evaluate the tradeoffs for the formatter with that knowledge in mind
Anton (Feb 28 2023 at 13:47):Sounds good, I've made #5078 for this.
Brendan Hansknecht (Feb 28 2023 at 16:22):Does this also apply to functions?
Brendan Hansknecht (Feb 28 2023 at 16:22):Like top level functions?
Brendan Hansknecht (Feb 28 2023 at 16:22):I think that could really bug people (like me) if so.
Anton (Feb 28 2023 at 16:37):To make sure I understand correctly @Brendan Hansknecht, you'd like to be able to define functions out of order and have them work? I think we should continue to allow that. I'll clarify that in #5078
Brendan Hansknecht (Feb 28 2023 at 16:40):I mean, really anything in the top level should be fine to define out of order. Constants, functions, etc. Though definitely functions is the main use case.
Richard Feldman (Feb 28 2023 at 21:17):yeah I don't think functions should ever get reordered
Richard Feldman (Feb 28 2023 at 21:17):the original motivation is to make sure that dbg and expects that are interspersed with defs don't print at surprising times
Ben Cohen (Mar 06 2023 at 18:13):Hi -- I'm new here but find myself very excited about roc -- I don't think I've ever come across a language vision with this potential. I'm possessing of some free time soon and will be looking to play with the language and build some toy platforms ... (Sorry for my first comment to be of the random drive by commenter variety)
But I think this idea is interesting ... I think the formatter is a very interesting unexplored tool space for language designers -- "the thing that happens when you save" is a powerful interaction space because it happens all the time and it happens while someone is actively interacting with the source code ... -- so I have a desire to push back against thoughts like "doesn't seem like something for a formatter" ...
This thought might be something more for an editor topic -- but as this topic involves actively exposing dependency information to the reader I thought maybe I'd mention a pet idea of mine here ...
I have recently become obsessed with what I consider a huge flaw in developer workflows that I think people haven't thought about that much -- namely -- unordered filesystem directories.
Because of unordered directories, most codebases are represented as a hierarchy of unordered bags of unordered files ... It's kind of insane but for most codebases there are no ordering guides to be had at all -- a new author reading a new codebase is forced to reconstruct a useful order for browsing based on their familiarity with the ecosystem or just by some semi-random exploring process that ultimately places a tax on the working memory of the reader to reassemble concepts like process lifecycle and data flow from the unordered file jumble.
I recently inherited a pure sql codebase representing a data analytics system that runs on a cloud platform -- and the first thing I noticed is that it's hard to understand an unordered collection of sql files ... I ended up renaming the files and directories with a numeric prefix so that alphabetic sorting would correspond to the numeric sort and where the numeric code provided a low tech encoding of the "runs-after" dependency graph -- the sql was declarative but there still existed a required or semantically useful declaration order. It was amazing to me how much easier the codebase became to reason about and to browse once this quite dumb technique was employed.
I'd love for the roc editor to have some ability to expose meaningful semantic information about declaration order and/or control flow and/or data flow be exposed through something like a dependency analysis based file ordering mechanism ...
I don't have anything specific in mind at the moment. But I just wanted to get my hope out there, perhaps to be remembered when folks are designing the roc editor "file navigation" widget -- I hope that said widget will be more capable than "hierarchy of unordered bags of unordered files".
Based on my experience even doing something like auto renaming files to have numeric prefixes, if done in a thoughtful manner, would be an improvement over the status quo provided by todays tools
Anton (Mar 06 2023 at 19:05):Welcome @Ben Cohen :)
I'm possessing of some free time soon and will be looking to play with the language and build some toy platforms
Awesome, feel free to post on zulip if you have any questions.
"the thing that happens when you save" is a powerful interaction space because it happens all the time and it happens while someone is actively interacting with the source code ... -- so I have a desire to push back against thoughts like "doesn't seem like something for a formatter" ...
There could be opportunities there indeed but another part of my reasoning was that I want to avoid that we implement costly "smart features" that have a bad annoying vs useful ratio. This made me think of an old tweet:
using microsoft word
moves an image 1 mm to the left
all text and images shift. 4 new pages appear. in the distance, sirens.
I think editor plugins are a better place for functionality like value definition re-ordering. The formatter will be widely used so I'd like to stick with safe and simple feature choices which will also help make it reliable and fast.
I ended up renaming the files and directories with a numeric prefix so that alphabetic sorting would correspond to the numeric sort and where the numeric code provided a low tech encoding of the "runs-after" dependency graph -- the sql was declarative but there still existed a required or semantically useful declaration order.
I like this idea, I'll save it for the editor ideas file :)
I regularly end up tracking down this flow manually and I think there are a lot of untapped opportunities to make projects more accessible for newcomers.
I'd love for the roc editor to have some ability to expose meaningful semantic information about declaration order and/or control flow and/or data flow be exposed through something like a dependency analysis based file ordering mechanism ...
Part of the reason for making our own editor was to allow for fast and free communication with the compiler so this functionality seems in line with our expected approach.
Brendan Hansknecht (Mar 06 2023 at 19:32):For the file naming a prefixes, i think that having a language server with "go to definition" and following the flow of the code is a huge part of being able to understand. That said, it can get quite complex and jump around a lot so maybe prefixes or some sort of smart ordering is better.
Anton (Mar 07 2023 at 08:47):We definitely want "go to definition" as well, but it could be nice to have similar info available at a glance with the prefixes.
Ben Cohen (Mar 08 2023 at 01:48):For sure, 'go to definition' would've helped a LOT for the sql codebase example ... I understand that roc's version of go-to-definition should be kind of the maximally good version - where 'cmd-click' only ever takes you to one place with roc (as opposed to oo/dynamic dispatch languages where even at the limit of the best possible static analysis, the editor can't know _where_ the body of the method call associated with a particular line of code is due to the curse of runtime dispatch ...)
But even with that very good implementation of go to definition being present -- I think there might still be a useful (deterministic) notion of 'in what order should I read and/or think about this code' that hopefully the editor will have a way to elevate ... I suppose this comment is really just an expression of a random "aspiration" -- but I appreciate the gracious responses and will look forward to reading and learning more!
Last updated: Jun 16 2026 at 16:19 UTC