Georges Boris (Aug 11 2022 at 16:28): Georges Boris (Aug 11 2022 at 16:28):hey folks - after the mostly positive reaction to my comment on #off-topic I thought it would make sense to generate a topic about it.
what would be the path to take to decide on going for slightly longer module/function names vs the current abbreviated ones?
I'd love to contribute on whatever boring manual work would be necessary to make it happen (if people decided going for it)
Georges Boris (Aug 15 2022 at 15:32):folks - about this. is it too late to propose the change? I know it looks cosmethic but one can make the case in the opposite direction.
or maybe it is just too much trouble at the moment to go through it and it will be something considered only for newer modules etc?
sorry for the repetition but I wanted to confirm :)
Brendan Hansknecht (Aug 15 2022 at 15:35):I think it is a fine change to make. I think the only place the change would be inconvenient would be Str to String. I think that most functions would be pretty simple to update the name of given most Roc apps currently have to keep up with the compiler anyway.
Brendan Hansknecht (Aug 15 2022 at 15:36):I think a good next step would be to make a github issue were we list the set of requested name changes. (might be a large task, but should be doable for roc builtin type names and function names)
Brendan Hansknecht (Aug 15 2022 at 15:36):After that, we can decide if any names aren't worth changing and update the repo with the suggested changes.
Richard Feldman (Aug 15 2022 at 16:00):yeah I think this is still definitely at the proposal stage - implementation would be premature!
Jurek Breuninger (Aug 23 2022 at 21:11):I just had a little e-mail conversation with Felienne Hermans about this. Like me, she couldn't think of any advantages of abbreviated module names except typing and experienced devs enjoying to be "in the know". She agrees that readable names would make Roc easier to learn.
Richard Feldman (Aug 29 2022 at 13:55):update on this: I exchanged some emails with Felienne Hermans too! She clarified some things, basically:
so it sounds like her expertise reaffirms the tradeoffs I originally expected when choosing the current design:
to me, this reinforces my intuition that Elm's use of Msg and Cmd and Dict are worth it, and similarly that Roc's use of Str is worth it
Richard Feldman (Aug 29 2022 at 13:58):all of which is to say: I'm not sold on this being a positive change for the language. It seems like the upside of making the learning curve a very small amount shorter (e.g. I am extremely skeptical that people are going to have a hard time learning "Str is short for String"!) is not worth the downside of common names being longer for everyone forever.
that said, this is absolutely a subjective area! There are no hard-and-fast rules I'm aware of (or that Felienne Hermans is, either, from what I can tell). It's a "where do you draw the line?" question - e.g. I think Dict is fine, but I prefer to write out ListWasEmpty in error types instead of like Lwe because I don't think that would be easy enough to learn/remember.
Richard Feldman (Aug 29 2022 at 14:01):I'm totally open to discussing on a case-by-case basis whether a particular name should or shouldn't be abbreviated, but I don't think adopting a blanket "no abbreviations" policy in the standard library is the right move, after considering the research
Brendan Hansknecht (Aug 29 2022 at 14:05):I think the main area where longer names matter is functions and errors. You simply don't interact with functions and errors nearly as often as you interact with types. So if is much more likely that you don't learn the abbreviations.
Brendan Hansknecht (Aug 29 2022 at 14:08):Also, there is a huge difference between a shortening that suggests the output well and a shortening where the mapping is hard to follow. Dict and Str are simple shortenings that people learn fast. lwe barely has any mapping to the real meaning and is hard to learn.
Last updated: Jun 16 2026 at 16:19 UTC