✔ reflecting on static dispatch... and discussing removin... · ideas

Stream: ideas

Topic: ✔ reflecting on static dispatch... and discussing removin...

Anton (Jan 13 2025 at 13:16):

This is going to look like I'm shitting on static dispatch again, which I don't enjoy, because many people are excited about it and have put in substantial work towards it.

Given what we know now, I'd like us to reflect back on static dispatch. It seems like the SD decision has more downstream consequences and is more disruptive then we expected. There has been a ton of discussion about SD related things, which implies it's not easy to get the details right. I'm also concerned that as we make ever more changes to create a nicely balanced language with SD it will be harder to decide to go back, in case we think the final transformation is not better then the old Roc. A looming 0.1 release and the general desire to be respectful and appreciative of others work also decrease the likelihood of reverting.

So given this additional info, now seems like good time to make sure we still want to do this!
We had a simple well balanced language before SD and it looks like we're taking a substantial risk now.

To remove some doubt on this communication through text, I'm not angry and I don't feel strong emotions about the static dispatch situation. I'm just rationally trying to help us make the best language.

Richard Feldman (Jan 13 2025 at 13:57):

I'm curious to get anyone's thoughts on this!

Anthony Bullard (Jan 13 2025 at 14:17):

I think this is very risky. I've been pretty vocal about that - and trying to move us into a different direction. But I think that I understand what we could gain with SD. But I think it would be an interesting exercise to have @Richard Feldman and others list out the pros/cons for SD with their current understanding.

Anthony Bullard (Jan 13 2025 at 14:20):

Here's my lists:

Pros:

Removal of abilities from the language
Terseness of chaining data / fewer qualified function calls
Better autocomplete (though I think there are other ways to improve this)

Cons:

Incentivizing nominal typing / moving away from structural
Loss of ability to understand where a function/implementation is coming from by reading the source

Brendan Hansknecht (Jan 13 2025 at 19:45):

I think it is very important to disambiguate the kinds of discussion. While static dispatch has promoted a lot of discussion and design churn, almost all of it is related to syntax. This says very little about the merit or lack there of for static dispatch. A very direct example is the partial application proposal. That proposal only exists because the syntax suggests that maybe it should exist. Same for many other proposal that came following parens and commas (which was added for static dispatch).

I feel like I see very little deep debate around fundamental designs. Most debates are around what syntax to pick and the possibilities opened by the syntax.

Brendan Hansknecht (Jan 13 2025 at 19:47):

These can be seen as disruptive downstream consequences, but I see them much more as minor syntax debates and new ideas sparked by the changes in syntax.

Brendan Hansknecht (Jan 13 2025 at 19:56):

As for pros and cons of SD...

Pros:

More autocomplete friendly (and mainstream syntax)
Replaces abilities with something simpler and easier to use/understand
Adds implicit interfaces (which enables very flexible composition and interoperability)
Removes a lot of repeated verbosity with Module names
Is still static calls (important for performance)
Tangential, but important: Comes with nominal types which enable a lot more flexibility in use than opaque types (like allow for pattern matching over nominal tags).

Cons:

Removes a significant part of the unique and joyful part of Roc's syntax that made it different from other languages (space based calling)
Could easily lead to too many nominal types (Though this is hard to quantify. In many languages there are only nominal types. Is having more really a problem)
More dependence on lsp "go to definition" to figure out an implementation
Awful default types for functions using static dispatch without concrete types (I really think forcing typing with an interface definition would be much more readable)
Could be totally avoid with many of the gains by just using records of functions and data. This would be dynamic dispatch and more verbose, but it would solve most of the same problems.

Sam Mohr (Jan 13 2025 at 19:58):

+1 to the forcing of typing as laid out in #ideas > Warning for unannotated exposed symbols

Anthony Bullard (Jan 13 2025 at 20:00):

Yeah, I think we'll come to wanting mandatory (even if provided automatically by LSP) annotation of all function signatures even if the compiler doesn't need it

Brendan Hansknecht (Jan 13 2025 at 20:01):

It's more than just forcing typing. It is forcing type aliases that are equivalent to interfaces. Like I want to see Hasher a rather than N different functions that relate to hashing.

Anthony Bullard (Jan 13 2025 at 20:01):

Yeah, or annotations will be HIDEOUS

Brendan Hansknecht (Jan 13 2025 at 20:02):

Yeah, I don't think I would want the autogenerated annotation on an SD function.

Anthony Bullard (Jan 13 2025 at 20:02):

Whether that's in the source text of the program, or in LSP Hover

Brendan Hansknecht (Jan 13 2025 at 20:02):

Yeah....lsp hover may be hard

Anthony Bullard (Jan 13 2025 at 20:03):

LSPs can do a lot. Generate a rough one right away, and then offer a code action to refactor a implements clause into a named interface type

Anthony Bullard (Jan 13 2025 at 20:04):

Could even find types in the project that meet the interface and allow you to sub the implements with that concrete type

Anthony Bullard (Jan 13 2025 at 20:04):

But man, we at that point might want to spool up the Roc Editor again :-)

Brendan Hansknecht (Jan 13 2025 at 20:06):

Anthony Bullard said:

Could even find types in the project that meet the interface and allow you to sub the implements with that concrete type

Yeah, this is fundamentally what I want most. Or, not only for concrete types, but also for interfaces (which are just static dispatch type aliases)

Sam Mohr (Jan 13 2025 at 20:53):

I think even in the short term, just requiring type signatures will make people see how ugly the inferred type is and strive for better

Sam Mohr (Jan 13 2025 at 20:53):

But giving them tools to make it easier would be great, of course

Richard Feldman (Jan 13 2025 at 21:14):

I know it's not quite the original topic, but quick note: it's been one of the longest-standing design goals in Roc to explicitly not require type signatures, to the point where a number of language design ideas have been ruled out just because they would require type signatures.

I always want to keep an open mind, of course, but ever requiring type signatures even in the short term is something I actively want to avoid. :big_smile:

Richard Feldman (Jan 13 2025 at 21:16):

I think if we want to make it easier to annotate top-level things, inline type hints in editors would be a great way to do it

Richard Feldman (Jan 13 2025 at 21:17):

both so you can just see what the type is even if it's not annotated, but also to create an incentive to make it look nicer so you're not seeing a weird inferred type that doesn't know what aliases to use

Sam Mohr (Jan 13 2025 at 21:17):

I think the lack of deep debate here is because Roc's type system with product types, sum types, and typeclasses via abilities or methods are enough to do everything we'd want a PL to do. We just want to make that more convenient now, which is why there's so much syntax discussion

Richard Feldman (Jan 13 2025 at 21:18):

that said, I do like the idea of requiring annotations in order to be accepted in the package index

Sam Mohr (Jan 13 2025 at 21:18):

Yeah, annotations are for people unfamiliar with your code

Richard Feldman (Jan 13 2025 at 21:19):

if you don't want to annotate your bash script equivalent, that's reasonable and makes sense, but we want a high quality ecosystem, and that seems like one of several reasonable quality control checks (alongside "it compiles" and "it was formatted with roc format")

Sam Mohr (Jan 13 2025 at 21:20):

Yep, we shouldn't require it on bash script equivalents, this is mainly for libraries

Richard Feldman (Jan 13 2025 at 21:24):

anyway, here's my list:

Pros:

Removing Abilities from the language
Removing optional record fields from the language (in favor of method-call builders, e.g. Json.utf8.transform(CamelCase) over Json.utf8_with({ transform: CamelCase }))
Removing module params for the language (in favor of passing around small stateful values that can have lots of functions on them without needing to carry around a ton of closures at runtime, and still be used concisely)
Removing tuple extensibility from the language (in favor of something like .get_0() for tuple field access)
Improved autocomplete experience
Conciseness (e.g. more functions fit on the same screen without scrolling)
More obvious module organization, e.g. a nominal UserId obviously gets its own UserId.roc so it can get static dispatch, whereas today deciding whether a small type like that gets its own module is a source of unimportant debate
Every module's documentation becomes "types and values" and that's it (like Elm, and like Roc was before Abilities) - I'm listing this separately from the "removing Abilities from the language" because there's a separate impact on documentation beyond the "no longer something anyone needs to learn or think about" aspect (like there also is in removing optional record fields and tuple extensibility, although neither of those impact docs significantly)
Parens-and-commas syntax (which is intended to facilitate static dispatch) is nicer when calling zero-argument functions, which are much more common now that we have purity inference (e.g. Dict.empty() compared to today's Dict.empty {})
Operator overloading without having to change anything's type (e.g. Num.plus can keep Num.add's current Num-focused type instead of having to become something like Num.add : a, a -> a where a implements Add)
It makes ad-hoc polymorphism structural; that is, two packages which share no dependencies can adhere to a common "protocol" involving static dispatch types of the same shape. Today, they can only have a common "protocol" by having a dependency on the same formal Ability. (If formality is desired, this can still be achieved by including an opaque type in the shared function shape; that way, anyone who wants to conform has to depend on that opaque type. The opaque type can even be a phantom type or zero-sized marker value.)
Static dispatch seems easier to teach than Abilities. (I already tried writing the tutorial section on the basic method-style calling version of it; it takes about a page of explanation, including walking through examples. The Decoding explanation will take longer—as it would with Abilities—but that can be deferred until later in the learning experience.)
4.(hours) and 4.(hours).(ago!) are very nice imo, and one of the things people love about Ruby syntax (except in this case with full type-checking instead of monkeypatching)
Larger community and ecosystem, due to more people trying the language because syntax looks more mainstream (likely a lot more, based on Gleam's experience report). I think this is a very significant benefit, but I listed it last because I've seen occasional reactions to people hearing about static dispatch as a knee-jerk "that must be only for beginner familiarity!" so I put it at the end of a long list of unrelated upsides to make it more obivous that it's a benefit but not the benefit.

Cons:

More parens in the syntax (unavoidable downside that comes with the upside of more mainstream calling syntax)
Less flexibility in where ad-hoc polymorphism is defined (e.g. you can't have a nominal UserId in the same module as User and have them both support ==; unavoidable downside that comes with the upside of more obvious module organization)
Since ad-hoc polymorphism is based on function names, function names become more semantically important and it becomes possible to accidentally choose a name which later turns out to conflict with seemingly-unrelated code. (This apparently is not a significant problem in practice in Go, which has a similar consideration with their Interfaces. This is an unavoidable downside that comes with the upside of structural ad-hoc polymorphism, and is a problem which could also theoretically happen with our structural records, tuples, and tag unions, but so far has not.)
Less self-descriptive code because of fewer fully-qualified calls (inlay hints can help with this in vertical call chains, but still not the same as before; unavoidable downside that comes with the upside of conciseness)
We haven't found a great syntax for the types of e.g. Decode (static dispatch in the return position instead of the argument position)
It's potentially easier for beginners to continue using familiar object-oriented architectures that don't fit the language (unavoidable downside that comes with the upside of code looking more familiar to beginners)

Richard Feldman (Jan 13 2025 at 21:27):

I'm actually not worried about overuse of nominal types, and I agree with Brendan that if they do end up being used more than I think is reasonable, I think the negative consequences would be pretty mild - mostly around code being a bit unnecessarily verbose.

I'd be more concerned about people making architectural mistakes that are harder to fix than realizing "oh hey this could just be a structural type and then my code would be more concise," especially considering programmers usually gravitate towards more concise options by default anyway :big_smile:

Richard Feldman (Jan 13 2025 at 21:28):

structural types do allow for certain patterns of data structure sharing, but I never saw much use of that in Elm, haven't seen much use of it in Roc, and don't really think it's a big deal if a feature that's almost completely unused today becomes even less used

Richard Feldman (Jan 13 2025 at 21:29):

as noted above in the Pros, I agree with Brendan's point that structural ad-hoc polymorphism seems like it has higher potential, especially because it means ecosystems can coordinate either with or without explicit dependencies, whereas with Abilities, explicit dependencies are the only option

Sam Mohr (Jan 13 2025 at 21:31):

The example of Arg := [Unix (List U8), Windows (List U16)] with a .from_raw_arg() method shows the power of methods to avoid needing ecosystem coordination

Sam Mohr (Jan 13 2025 at 21:31):

In a young ecosystem like Roc has, we can't depend on there being a solid foundation for people to rely on for things like HTTP, datetime, UUIDs, etc

Sam Mohr (Jan 13 2025 at 21:32):

So that makes code more modular in an awesome way

Anthony Bullard (Jan 13 2025 at 21:33):

Richard Feldman said:

I think if we want to make it easier to annotate top-level things, inline type hints in editors would be a great way to do it

I see you bring this up a lot. But maybe this is Architect / Staff engineer brain - but I read most code in GH / Pull requests. I don’t get that benefit there. And that hurts a lot, and a big reason I hate Java

Sam Mohr (Jan 13 2025 at 21:33):

+3 right there

Sam Mohr (Jan 13 2025 at 21:33):

Was about to write the same thing: if you need an editor to engage with Roc, we're now Kotlin

Anthony Bullard (Jan 13 2025 at 21:34):

It’s that way with a lot of languages

Sam Mohr (Jan 13 2025 at 21:34):

Yep

Anthony Bullard (Jan 13 2025 at 21:35):

Way GH hasn’t made a VSCode-like interface with LSP interactivity (but read only) as the default for viewing code I’ll never understand

Sam Mohr (Jan 13 2025 at 21:35):

Because that would cost money, right?

Anthony Bullard (Jan 13 2025 at 21:35):

And I know, VSCode eww, but people can’t find a way to put Neovim in the browser

Anthony Bullard (Jan 13 2025 at 21:36):

Sure, but they make workspaces available for free

Anthony Bullard (Jan 13 2025 at 21:36):

At least make it the default for PRs

Sam Mohr (Jan 13 2025 at 21:36):

Maybe some form of required module qualification for "main" expressions in top-level functions and values would help with this readability problem?

Anthony Bullard (Jan 13 2025 at 21:36):

I’d pay for that

Anthony Bullard (Jan 13 2025 at 21:37):

Sam Mohr said:

Maybe some form of required module qualification for "main" expressions in top-level functions and values would help with this readability problem?

Could you expand on this?

Sam Mohr (Jan 13 2025 at 21:37):

I think that Roc with methods is so simple, the only problem I have with it is readability without module qualification.

Richard Feldman (Jan 13 2025 at 21:37):

Anthony Bullard said:

Richard Feldman said:

I think if we want to make it easier to annotate top-level things, inline type hints in editors would be a great way to do it

I see you bring this up a lot. But maybe this is Architect / Staff engineer brain - but I read most code in GH / Pull requests. I don’t get that benefit there. And that hurts a lot, and a big reason I hate Java

I think there's a big gap between languages with inheritance and those without though

Richard Feldman (Jan 13 2025 at 21:38):

like when I see a method-style call chain in Rust, it takes me a little bit longer to figure out which maps are for collections versus Options/Results compared to module-qualified function calls which just give me the answer right away

Anthony Bullard (Jan 13 2025 at 21:39):

I think ad-hoc polymorphism is largely the same issue

Richard Feldman (Jan 13 2025 at 21:39):

well but in that case, we're in the same boat today

Richard Feldman (Jan 13 2025 at 21:40):

e.g. if I call |> Bool.isEq or |> Inspect.toStr, that tells me me anything about the types involved

Anthony Bullard (Jan 13 2025 at 21:40):

True, but abilities are so complex to use, I generally don’t (outside of builtins)

Richard Feldman (Jan 13 2025 at 21:40):

so that's not a static dispatch thing, it's an ad-hoc polymorphism thing

Anthony Bullard (Jan 13 2025 at 21:40):

Richard Feldman said:

so that's not a static dispatch thing, it's an ad-hoc polymorphism thing

True

Richard Feldman (Jan 13 2025 at 21:40):

I don't think that will change much other than operator overloading

Richard Feldman (Jan 13 2025 at 21:40):

e.g. the realworld code base only used operator overloading compared to today

Richard Feldman (Jan 13 2025 at 21:41):

and in that case the units made the types clear, e.g. in Clock.now!() + 4.(hours) I'm not wondering what types are involved :big_smile:

Richard Feldman (Jan 13 2025 at 21:41):

actually one of the biggest surprises in that code base was how even without inlay hints, I still knew what the types were almost always

Richard Feldman (Jan 13 2025 at 21:42):

one of the things it did make me wonder is whether we should consider renaming map in some cases, because that's the biggest offender right now in terms of ambiguity

Richard Feldman (Jan 13 2025 at 21:42):

like if we have .try(...) as opposed to .and_then(...) I take one look at that and I'm like "oh hey, that's Result.try!"

Richard Feldman (Jan 13 2025 at 21:42):

whereas and_then could be anything

Richard Feldman (Jan 13 2025 at 21:42):

similarly, if I see .map(...) I don't know if it's a collection or a Result or what

Richard Feldman (Jan 13 2025 at 21:43):

of course, that is the accepted name for that operation

Sam Mohr (Jan 13 2025 at 21:43):

We do map and map_err, but map_ok and map_err would make more sense

Richard Feldman (Jan 13 2025 at 21:43):

wow, I love that idea!!!

Richard Feldman (Jan 13 2025 at 21:43):

that would actually make a big difference right away

Sam Mohr (Jan 13 2025 at 21:43):

Name things based on the types!

Richard Feldman (Jan 13 2025 at 21:44):

and it makes it more obvious what the function is doing, wowwww

Sam Mohr (Jan 13 2025 at 21:44):

We didn't used to need this because everything was module qualified, so the Result.map is actually the full name. Now that the full name is just map, we need a better name

Richard Feldman (Jan 13 2025 at 21:44):

yeah, except that .map_ok() is somehow actually more concise and more descriptive than Result.map

Richard Feldman (Jan 13 2025 at 21:45):

they both tell you it's a Result (nothing else uses "ok") but with Result.map you have to know it's operating on Ok

Sam Mohr (Jan 13 2025 at 21:45):

It may make sense to do this for other types... List.map_items? Dict.map_entries?

Richard Feldman (Jan 13 2025 at 21:45):

yeah, so it would be rad if we could find more wins like that

Richard Feldman (Jan 13 2025 at 21:45):

maybe!

Richard Feldman (Jan 13 2025 at 21:46):

or like List.map_elems or something

Sam Mohr (Jan 13 2025 at 21:46):

Those are less obvious than map_ok

Richard Feldman (Jan 13 2025 at 21:46):

yeah

Richard Feldman (Jan 13 2025 at 21:46):

could be worth experimenting with

Richard Feldman (Jan 13 2025 at 21:46):

but yeah, if we could get method-style names that are more self-descriptive in a way that means you can instantly know the types of things involved, while still getting all the other benefits of static dispatch, that would be awesome

Sam Mohr (Jan 13 2025 at 21:48):

For Anthony:

I just want to know what the arg types are on top-level functions when reading someone else's code. One way we can do that without requiring type annotations is for method chains to have the first function call required to be a module-qualified function call instead of a method call. This is tricky because functions can have definitions and control flow, not sure what to do there. If we don't name methods to imply what they're acting on (as suggested just now), then this would be more readable to me:

get_third_valid_item = |items|
    List.map(items, |item| foo(item))
    .keep_oks(|item| ...)
    .get(2)

Sam Mohr (Jan 13 2025 at 21:50):

As opposed to what would now be allowed:

get_third_valid_item =
    .map(|item| foo(item))
    .keep_oks(|item| ...)
    .get(2)

Sam Mohr (Jan 13 2025 at 21:50):

Anyway

Sam Mohr (Jan 13 2025 at 21:52):

for the above naming discussion, this was something I needed to figure out when I wrote Weaver. The name always included the module, so it wasn't SubCmd.required_subcommand, it was more obviously SubCmd.required.

Richard Feldman (Jan 13 2025 at 21:52):

I'd say the top 5 things I'm most excited about with static dispatch are:

between all the semantic language feature deletions and the "modules are just types and values, that's it," it really feels like a wonderful step in the direction of a language that has "a small set of simple primitives that work well together"
nicer autocomplete
simpler, structural ad-hoc polymorphism
delightful little Ruby-style syntax things like 4.(hours) (helps balance out some of the longstanding fondness I have for whitespace calling)
making the language much more approachable to a much larger group of beginners

Sam Mohr (Jan 13 2025 at 21:52):

Any function that will probably be module-qualified should consider the module to be part of the name

Sam Mohr (Jan 13 2025 at 21:54):

So Cli.weave should not be called weave_cli since Roc makes it much easier to do import Cli over import Cli exposing [weave_cli]

Sam Mohr (Jan 13 2025 at 21:54):

In short, I look forward to naming conventions aligning based on functions being primarily used as methods vs. as normal functions

Sam Mohr (Jan 13 2025 at 21:54):

It'd be nice to include this kind of thing in the tutorial

Richard Feldman (Jan 13 2025 at 21:57):

yeah I think a light touch might go a long way here

Richard Feldman (Jan 13 2025 at 21:58):

honestly the biggest situation I've noticed that gives me pause has been specifically not knowing whether .map referred to a collection or to a Result, and map_ok instantly solves that one in a super nice way

Richard Feldman (Jan 13 2025 at 21:59):

and we don't have Option or Maybe, so that's not a problem either

Richard Feldman (Jan 13 2025 at 22:00):

I think it'll be interesting to keep an eye out for what specific scenarios come up where the types feel uncertain, and whether naming tweaks could help

Richard Feldman (Jan 13 2025 at 22:01):

because there is a learning cost to giving everything totally unique names, so ideally we could reach for it only in the specific situations where it's solving a problem

Richard Feldman (Jan 13 2025 at 22:02):

(and obviously in the case of wanting to do ad-hoc polymorphism the names will naturally be the same, but as discussed earlier, that comes with the territory with ad-hoc polymorphism!)

Sam Mohr (Jan 13 2025 at 22:03):

A lot of times, variable names can tell you the type of a thing. emails_per_employee feels like a Dict _ Str/Email, I don't want to have to write dict_* if I can just name the args

Richard Feldman (Jan 13 2025 at 22:07):

yeah, I often use by when it's a dictionary, e.g. users_by_email

Richard Feldman (Jan 13 2025 at 22:22):

sightly off-topic, but when I originally decided to intentionally omit a Maybe or Option type from the stdlib, I really underestimated the positive impact it would have to use Result everywhere

Richard Feldman (Jan 13 2025 at 22:22):

like it's been way more than a nice little simplification

Sam Mohr (Jan 13 2025 at 22:26):

The downside has been worries around discarding the info in the error a la ??, but that's way better than just discarding info about the error case at the type level with Option

Brendan Hansknecht (Jan 13 2025 at 22:52):

To me, map is a more fundamental operation that is free from the container

Brendan Hansknecht (Jan 13 2025 at 22:52):

So knowing the container type isn't really a gain

Brendan Hansknecht (Jan 13 2025 at 22:52):

In fact, it makes it impossible to be generic over the container type

Brendan Hansknecht (Jan 13 2025 at 22:52):

So I prefer everything as simply map

Brendan Hansknecht (Jan 13 2025 at 22:53):

Result is special probably, but a kv list and a dict are the same thing from the perspective of mapping.

Brendan Hansknecht (Jan 13 2025 at 22:53):

Or a list and a linked list

Sam Mohr (Jan 13 2025 at 22:54):

Without HKT, we can't make a map method generic anyway

Luke Boswell (Jan 13 2025 at 22:54):

I think just Result.map_ok may be all we need here, it's a light touch but I suspect will cover the 80%

Brendan Hansknecht (Jan 13 2025 at 22:56):

Sam Mohr said:

Without HKT, we can't make a map method generic anyway

Not exactly true. The types will be dumb, but it will work.

Sam Mohr (Jan 13 2025 at 22:57):

map_over : (a, (?) -> ?) -> b

Sam Mohr (Jan 13 2025 at 22:57):

What are the two question marks here?

Paul Stanley (Jan 13 2025 at 22:59):

I don't particularly feel qualified to have an opinion, and I'm always in favour of trying things out. That said for me the main cons are that static dispatch brings with it:

A good deal of obscure magic. Yes, fully qualified functions are annoying sometimes, but they do really increase expressness in a good way. There's a reason why it's a generally held wisdom in, e.g., OCaml _not_ to open modules globally. I think people are going to find some odd surprises, and it's going to be very hard to make the LSP story so good that they disappear.
I dislike treating functions as if they were methods. To me foo.dobar(blah).doobaz(blahblah) looks as if dobar and dobaz are in someway features of foo. But they are not, and actually they (or, anyway, any call other than the first) may be operating on things that have a completely different type from foo. Pipelines seem a better metaphor to me (and even they can be over-used). map is not a thing a list can do it is a thing you can do to a list, and it's first argument is no more semantically significant than its second.
I happen not to like syntax where a simple little dot means "call a function". The . (not a very conspicuous little fellow) ends up massively overloaded: sometimes it means decimal point, sometimes it means record field access, sometimes it means call a function.
I've never loved a proliferation of parentheses. One of the reasons ML type languages end up with pipe operators is to avoid them. I don't hate them is Lisp, but there they come alongside an elegantly simple s-expression syntax. In the end, they too end up "overloaded" with meaning, sometimes signalling grouping, sometimes signalling function arguments ... it's a mess. The fact it's a familiar mess in lots of languages makes us not notice the mess, but it's a mess.

So personally those are downsides which for me outweigh the upsides. But I say that as a total amateur _and_ someone who has spent much more time with functional languages, especially ML-lie ones, so _for me_ the existing patterns are more familiar.

Anton (Jan 14 2025 at 16:14):

By the way, I am satisfied with the collective reflecting that was done :)

jan kili (Jan 14 2025 at 20:53):

To see a demonstration of these pros/cons, what's the most complete/thorough/realistic example of an SD-ful Roc app?

Luke Boswell (Jan 14 2025 at 20:59):

@JanCVanB see #show and tell > roc-realworld initial exploration @ 💬

Eelco Hoekema (Jan 25 2025 at 16:10):

Cons:

Removes a significant part of the unique and joyful part of Roc's syntax that made it different from other languages (space based calling)

This, 100%.

Ian McLerran (Jan 28 2025 at 21:21):

I have been hesitant to express too much in terms of negative feelings about the SD changes, as I hugely admire all the thought and work that has gone into the planning (and implementation work thus far), and I believe in the principal of "Disagree and Commit". I also can appreciate many of the benefits, such as doing away with abilities and module imports.

With that said, I also 100% agree on the joyful part of Roc's syntax. There are a few things that drew me to Roc, and many of those are unrelated to syntax, but I will say that Roc has had my favorite syntax of any language I have written prior. That is coming from someone who almost exclusively wrote PNC style languages, except for a little Haskell, which was my first and only exposure to ML style languages. While I found Haskell intriguing, I didn't fall in love with it.

Roc, meanwhile, took many of the things I liked from Haskell and turned them into something I absolutely love. I love the expressiveness of Roc, the freedom from parenthesis hell, and the clear logic flow expressed by the pizza pipe operator. I have found Roc syntax to be some of the most enjoyable I have ever written, and it has really given me an appreciation for ML syntax.

While I am open to trying out SD, and as I said before I do appreciate some of the benefits and even acknowledge that SD may be worth the loss, I have to say that I am definitely among those mourning the change of syntax. I will miss the light use of parens, the expressiveness of qualifiers, and the flow of the pizza operator quite a lot.

Brendan Hansknecht (Jan 29 2025 at 01:44):

What is the principal of "Disagree and Commit"?

jan kili (Jan 29 2025 at 01:52):

https://en.m.wikipedia.org/wiki/Disagree_and_commit

Disagree and commit is a management principle that individuals are allowed to disagree while a decision is being made, but that once a decision has been made, everybody must commit to implementing the decision. Disagree and commit is a method of avoiding the consensus trap, in which the lack of consensus leads to inaction.

Ian McLerran (Jan 29 2025 at 02:14):

Yep, exactly. I mention it because I have been feeling a bit like SD is a done deal, and it’s time to commit, and this has been part of the reason I haven’t expressed much. But since this thread is still kicking, and since SD is not yet here, I thought I’d voice a few last thoughts on the changes before it really is too late to say anything.

Hannes (Jan 29 2025 at 10:56):

I haven't said anything on all the static dispatch changes for similar reasons to Ian, I just want to link to a thread I made a while ago on Roc's syntax :sweat_smile:

Elias Mulhall (Jan 30 2025 at 04:37):

Similar story here -- as a pretty casual community member I feel disappointed about the changes in syntax, but understand that it's related to a big ol semantic change that has already been talked to death.

Elias Mulhall (Jan 30 2025 at 04:43):

What initially sold me on Roc was the prospect of it being a friendlier OCaml, or a more generalized Elm. I realize it can still be that with a different syntax, but the vibe is different and I'm having a harder time than I really should coming to terms with that.

Brendan Hansknecht (Jan 30 2025 at 05:15):

there are lots of us

Wymin (Jan 30 2025 at 05:25):

Long time lurker here, but wasn't there a thread/conversation about possibly revisiting syntax with spaces once SD is in place and in use? Combining static dispatch with the pizza slice / pipe operator?

Anton (Jan 30 2025 at 08:39):

Is it this one: #ideas > static dispatch - spaces vs parens @ 💬

Wymin (Jan 30 2025 at 10:05):

Ah yes, that is the conversation I remember reading. Although I couldn't gather by the end of the conversation if there were concrete plans to revisit static dispatch using spaces and |>. There were some mentions of it, but nothing explicit.

Anton (Jan 31 2025 at 09:42):

There are no concrete plans to revisit static dispatch using spaces and |>but things may change if we end up not liking static dispatch with parens and commas

Dawid Danieluk (Jan 31 2025 at 12:06):

I see there's a lot of negativity about the syntax, so I'll be the opposite voice. I suspect that previous Roc syntax naturally attracted people that tend to like whitespace and dislike parentheses which is partly why last messages express negative sentiment (it's big 'vibe' change and because Roc started a certain way I think there's some audience capture at play here).

I came to Roc mainly because I'm somewhat dissatisfied with TS (I've written Golang, some Rust but at work I'm NodeJS dev). I like the subset of TS very much, my opinion is contrary to the mainstream here but it's very flexible language. I don't care that much about the syntax but even in that department TS is imo very good language.

What drew my attention to roc:

pragmatic approach to functional programming (with escape hatches planned like regular for loops)
compiled (I hate the fact that I'm compiling to interpreted language - it bothers me probably more than it should)
very flexible
specialized using platforms (personally I'd love to use it in 4 domains: webservers, plugins, embedded, replacement for shell scripts)

For me it being whitespace based language decreased readability and I prefer how realword.roc looks with pnc (talking about richards repo) over how it would look with whitespace syntax. I can get used to any syntax, but even when I do there will still be some cognitive load when jumping between few languages in one monorepo and having them use similar syntax might help in that regard.

Just wanted to leave a comment that not everyone is dissatisfied with syntax changes and there are people that prefer it visually :P To me new syntax is still lovely, just in different way :-)

Anton (Jan 31 2025 at 12:39):

Thanks for sharing @Dawid Danieluk!

Krzysztof Skowronek (Jan 31 2025 at 16:06):

Well, coming from C# and its extension methods, this new syntax feels right at home. I also was drawn to Roc due to F# like (or Elm like) pipe operator, but mostly because I like having functions just transform data from A to B and I want it to be easy to chain call the happy path and make the errors kinda handle themselves.

C# is pretty good at this, all it's missing is build in Result and ? operator (like in Rust).

After watching Casey Muratori "Clean code, horrbile performance" I though of looking for a C# replacement - something still productive, a bit lower level, where I can do everything. There is nothing outthere to do that.

Rust is just too... Rusty to for example replace our 1.6mln lines of C#. Zig is way too low level. Swift is nice, but too closed off and compiler sucks (and doesn't run on Windows too well).

Go? I just don't like it, and I haven't found a good way to use it to build native GUIs.

I have really high hopes for Roc to go straigh into empty bucket - productive, low level language for everything. I don't really care for syntax that much, I just want it to be "nice", with good LSP (C# with Rider is still the best coding experience on the market, I will die on that hill) and good debugger (Rust, I am looking at you).

I like the concept of platforms (as long as they are not blocking, meaning I want to add interproc communication between my GUI instances, but green pipes are not on platform and that's it), I like the functional nature with escape hatches with for loops.

I like the low level. I like the familiarity coming from C# - with static dispatch there is way higher chance that if I show Roc to coworkers, they will like it.

From my side - do whatever you need to do with syntax, just finish the project :)

BTW, C# has expression trees that allow for compile time parsing of lambdas body and for example transform them into SQL and SO MUCH MORE (like autogenerating GraphQL querries) - the ripple effect of this feature is enourmus.

I would LOVE to see something like that in Roc

Brendan Hansknecht (Jan 31 2025 at 16:09):

I feel like for me (someone who comes from the land of parens and commas), roc was initially weird for using space calling convention, but after getting used to it, it was a more whimsical language because of it.

So I think it is losing some vibes and whimsey, but don't think that is really what roc should be optimized for. So I think PNC makes total sense.

I feel like this will mostly end up being collective reminiscing more so than it will be dislike of the new syntax once we all get used to it.

Brendan Hansknecht (Jan 31 2025 at 16:10):

With the caveat of DSLs. I think those generally work better with space calling convention

Yunti (Jan 31 2025 at 17:56):

I'm not worried much about syntax, but as this thread shows (given the proportion of discussion towards it) it does matter a lot, and in terms of attracting people to a language (and as per other examples where reason initially did a good job of attracting people to Ocaml - before politics got in the way).

Great pros and cons summary, Richard thanks for sharing that. Quick thoughts on those:

It makes ad-hoc polymorphism structural; - I think this will end up being very important in terms of the possible impact to the ecosystem in the future
Parens-and-commas syntax - is important as mentioned above - but hopefully people already here will care more about a language than its syntax (so far it seems they do).
Static dispatch seems easier to teach than Abilities - this is another good point - simpler yet not losing functionality

The cons you mentioned in my view seem fairly minor, but Paul Stanley's first point touched on what I feel is a more important con - possibly less explicit language. But that's probably a flip side of more streamlined ad-hoc polymorphism.
Which is probably a good trade....

jan kili (Feb 07 2025 at 19:39):

I want to revive/start a discussion on the state of WSA. @Sam Mohr does this unresolved topic look better to resolve or resurrect?

Sam Mohr (Feb 07 2025 at 19:39):

Yeah, this is probably a good place to have the discussion

Sam Mohr (Feb 07 2025 at 19:39):

I don't think invoking Godly power is conducive to good discussion, but it seems in all the discussion that we've been having, our BDFN is not planning on WSA being in the language unless there's really strong opposition to PNC.

Sam Mohr (Feb 07 2025 at 19:40):

We have been politely keeping WSA around for the folks that prefer Roc with WSA because it wasn't really getting in the way of all the rewriting work we were doing

jan kili (Feb 07 2025 at 19:41):

For anyone unfamiliar with what "whitespace application" (WSA) means, it's this: five = add 2 3

Sam Mohr (Feb 07 2025 at 19:41):

Thanks for the clarification!

jan kili (Feb 07 2025 at 19:41):

instead of this: five = add(2, 3)

Sam Mohr (Feb 07 2025 at 19:41):

But now, Roc is planning on a giant overhaul that will rewrite not just 90% of the compiler, but 100%

Sam Mohr (Feb 07 2025 at 19:42):

So any features that "weren't in the way" like WSA and abilities were okay to _delay the removal of_, but to add them in the Zig-based Roc compiler would mean we'd now be implementing features that we don't seem to want in the 0.1.0 compiler

Sam Mohr (Feb 07 2025 at 19:43):

Which is "wasted" work, where wasted means it doesn't work towards the current vision of Roc

Sam Mohr (Feb 07 2025 at 19:44):

However, implementing WSA would work to the end of allowing folks that think we could have some future with WSA in Roc long-term to prove their case by showing its benefit over PNC (parens and commas based function calls)

Sam Mohr (Feb 07 2025 at 19:45):

So now, it seems we should collectively decide if we want to implement WSA in the new compiler to fulfill that promise, and I think a lot of the WSA advocates agreed to start with PNC in the first place because of said promise

Eli Dowling (Feb 07 2025 at 19:52):

I think it would be nice to have a single canonical explanation for why WSA is being removed with some answers to common questions such as:

What WSA version of static dispatch was considered and why was it rejected.

I think if I came to check on roc and discovered it's syntax totally changed I would want a sense that it was well considered if I was to maintain trust in the idea that roc is likely to succeed.

Maybe a "Why does roc looks so different?" with a little summary of some of the recent changes would be good. The recent hacker News conversation about roc was very syntax focused. Like it or not, it's what people notice.
I feel like it would have been great if the top reply to those negative comments could have been a link to a well considered explanation of the reasons behind the changes.

jan kili (Feb 07 2025 at 19:55):

a lot of the WSA advocates agreed ... because of said promise

Yes, before I get into any logical thoughts on PNC, I want to voice this primary emotion without accusing anyone of bad intentions - the deprecation of WSA has felt (and now feels extra) sneaky and dismissive because of how it's seemed that its advocates always get redirected in discussions.

The PNC proposal explicitly stated that WSA deprecation is independent of PNC addition, so WSA was kind of out of scope for that discussion.
I don't remember a WSA deprecation discussion ever officially starting, but I remember assurances that it wasn't going anywhere any time soon.
During PNC implementation, it felt that people wanted to prove PNC's value without planning any feature-parity with WSA.
WSA became somewhat synonymous with DSLs, because everyone seemed to prefer how DSLs look in WSA.
Now that the compiler is getting re-written, it feels like WSA is expected to prove why it should be added, not why it shouldn't be removed.

Sam Mohr (Feb 07 2025 at 19:57):

It seems like something that would be required for WSA to happen would be a syntax proposal for using static dispatch with WSA and no PNC

jan kili (Feb 07 2025 at 19:57):

I feel like many people have been quieted in their pushback against PNC because they were told that WSA wasn't going anywhere. Now that it is, it feels appropriate to reach out to everyone who was told that WSA wasn't going anywhere and gauge their discontent if it were to actually disappear tomorrow. I see almost no path for WSA support if it isn't addressed before the rewrite.

Sam Mohr (Feb 07 2025 at 19:58):

I'm not sure who would be in charge of that, but it would move the discussion away from "WSA can't do static dispatch, so it's out of the question"

jan kili (Feb 07 2025 at 19:59):

As for my logical thoughts on the merits of PNC, I think it feels alright and could be the right choice for Roc. However, "not like this" - I just want the community to have a chance to voice their opinions on what's actually happening and have our trustworthy BDFN either approve the democratic consensus or take a firm stance on overriding it.

jan kili (Feb 07 2025 at 20:00):

CC @Richard Feldman

Sam Mohr (Feb 07 2025 at 20:01):

I think this is the wrong thread, can someone with inter-channel perms (@Luke Boswell @Brendan Hansknecht ?) move this discussion block to #ideas > reflecting on static dispatch

jan kili (Feb 07 2025 at 20:01):

I gotchu

jan kili (Feb 07 2025 at 20:01):

Everything in here today?

Sam Mohr (Feb 07 2025 at 20:01):

yep

Sam Mohr (Feb 07 2025 at 20:01):

And then we can ping the WSA advocates in that centralized discussion to see if anyone could take lead on organizing a case for WSA working with static dispatch

Notification Bot (Feb 07 2025 at 20:02):

24 messages were moved here from #contributing > 🚨 Whitespace application and whitespace - breaking change! 🚨 by JanCVanB.

jan kili (Feb 07 2025 at 20:03):

@Sam Mohr Do you want me to resolve that other thread, then? Or do you want it for implementation chat?

Sam Mohr (Feb 07 2025 at 20:04):

If you're talking about #contributing > 🚨 Whitespace application and whitespace - breaking change! 🚨 , I don't think it matters

Sam Mohr (Feb 07 2025 at 20:05):

Thank you for pushing back here @JanCVanB , I've definitely been more focused on "How can I help implement the Roc I want ASAP?" over "How can I help make Roc a great language that we all like?". It's important to have self-advocates to remind me what's really important.

jan kili (Feb 07 2025 at 20:12):

I never wanted Roc to have two function application syntaxes forever, but it was a great way for us to see how PNC feels without making a big breaking change. If the rewrite is prompting this month to be the syntax choosing month, then we can finally do thorough side-by-sides in that context of finality.

Sam Mohr (Feb 07 2025 at 20:15):

So, in the meantime, I'll ping everyone I see in this thread that seems to have been in favor of keeping WSA (whitespace application) over PNC (parens and commas):

@Anton
@Brendan Hansknecht
@Anthony Bullard
@Paul Stanley
@Eelco Hoekema
@Ian McLerran
@Elias Mulhall
@Yunti ?

Please read the above discussion to get some context about how we are probably moving up the WSA removal date in light of the Zig rewrite. As such, it falls to someone on the WSA side, ideally one of you, to help us figure out a plan that the team would potentially agree on for a candidate matching the currently planned PNC + static dispatch.

jan kili (Feb 07 2025 at 20:15):

To many in this thread, I expect "moving up the WSA removal date" to read as "creating a WSA removal date"

Sam Mohr (Feb 07 2025 at 20:16):

Now, having done that, a very important disclaimer: please help us work together to have a polite, cooperative discussion that lines up our options side-by-side without this becoming a fight of volume of people or volume of yelling

Eli Dowling (Feb 07 2025 at 20:18):

I feel like the big issue with my own (and others) feelings about WSA is that it's pretty much "I just like it more". That's not really a compelling argument, but it does matter.

Every time I'm writing code in JS and I have to dick around adding and removing brackets to add a new function call... It just sucks. It's not fun and I think "I wish i was writing Ocaml".

It would be a shame to think that while writing roc.

I've not weighed into the WSA PNC debate because u didn't feel like I had much to add, but I feel like I should at least lend my support.

jan kili (Feb 07 2025 at 20:18):

@Sam Mohr Do you see complete feature/support parity between PNC & WSA except for a consensus syntax plan for how to call functions via static dispatch?

Sam Mohr (Feb 07 2025 at 20:19):

Yeah, from an impl side, I don't think there's a reason why one wouldn't work in-place of the other

Sam Mohr (Feb 07 2025 at 20:20):

It just needs us to ensure there's a logical and readable syntax for everything in both WSA and PNC

Sam Mohr (Feb 07 2025 at 20:20):

I make this ping because Roc has found great success in many people with different perspectives coming together to build what they think is the right language. Trying to arrive at a democratically-agreed solution is always preferred because we want everyone to be happy

Eelco Hoekema (Feb 07 2025 at 20:23):

In terms of feeling, it feels attracting new people from javascript world seems to be the main driver, retaining people from elm world is irrelevant.

Again, it is the full right of the language leadership to choose that direction. I am not a contributor, my opinion is hardly relevant. But it is disappointing from my perspective.

Sam Mohr (Feb 07 2025 at 20:23):

That said, it's not a perfect democracy, because we have a BDFN. I am obviously not Richard, so it's not my place to make a decision, but I am re-opening this real can of worms because it seems that we can't make everyone happy, and no one will be satisfied unless we put fairly considered options on the table and then our BDFN helps us in making a decision

jan kili (Feb 07 2025 at 20:23):

Sam Mohr said:

It just needs us to ensure there's a logical and readable syntax for everything in both WSA and PNC

Since static dispatch isn't yet implemented and the compiler rewrite seems to essentially freeze new feature development in Rust, does that mean that

full static dispatch will land in several months with v0.1.0?
until then, WSA can still already do everything PNC can do?

Eli Dowling (Feb 07 2025 at 20:24):

It might be worth making a thread specifically to list the syntax proposals, with discussion in other threads. I'm not very aware of what has and hasn't already been proposed, and the proposals often just get lost in discussion.

Sam Mohr (Feb 07 2025 at 20:24):

Until something like that happens, it seems like we're cooking up a good deal of unhappiness here

jan kili (Feb 07 2025 at 20:25):

Thank you kindly for helping me reopen this can of worms Sam :smile: :heart_hands:

Anthony Bullard (Feb 07 2025 at 20:26):

I am not in favor of keeping WSA. We’ve discussed a number of reasons why we chose PNC to enable static dispatch and why WSA just doesn’t work in a way people like with that feature.

And I do not want two different application syntaxes.

But again I’m all in on PNC because we evaluated it as the best choice for SD and (less important) onboard more mainstream users. That call was made not by me, but by the BDFN. I just implemented the PNC syntax.

I personally appreciate WSA in the abstract and would be totally happy using Roc with it. The semantics of the language are what are most important to me. But I also really enjoy the consistency of PNC and never running into a precedence issue with application.

Anthony Bullard (Feb 07 2025 at 20:29):

Zig and Rust are both two pretty terrible languages aesthetically, but are both powerful and fun to program in in their own ways. If Zig had WSA it might be 30% more aesthetically pleasing , but if it hurts its expressive power in some way by 1% I would be totally against it

Brendan Hansknecht (Feb 07 2025 at 20:34):

I don't have any compelling argument for WSA aside from DSLs. Well I'll miss it, I'm sure I'll get over it shortly. I thought it was pretty clear it was getting removed, but I guess it wasn't clear to everyone. I really saw this thread more as a way to feel a little sad about its removal than a discussion about keeping it around.

At this point, I think WSA is to die and that is fine. It will have a soft place in my heart, but I don't think it is worth trying to keep around in roc.

jan kili (Feb 07 2025 at 20:59):

CC @Sky Rose @Jonathan

jan kili (Feb 07 2025 at 21:00):

(from the related #ideas > static dispatch - spaces vs parens )

Sky Rose (Feb 07 2025 at 23:06):

My unsorted opinions:

WSA is more aesthetically pleasing, nicer to write in, I'd miss it a bit.
The approachability / standardness of PNC is huge and matters a lot. I have a friend I tried to tell about Roc, who took one look and said that WSA is a deal breaker for her getting into a language. I find this to be a pretty shallow opinion, but also I can't tell her that her opinions are wrong, and I think this is a pretty common opinion, especially among the masses who aren't represented well in this forum. It's a very small bump in the learning process, but it comes in the first minutes of using a language when it matters most.
WSA is a little better for writing DSLs, but so are macros. There are good reasons to exclude macros from the language. If there are good reasons to do PNC over WSA, then clunkier DSLs are not a dealbreaker.
In Elixir, being able to use either WSA or PNC leads to occasional mild annoyances. Lint failures, docs that don't match my code, having to think through which format to use for which use case, and so on. Formatters _mostly_ fix this, but not entirely. If we have both WSA and PNC, then there should be one right way to do any one task, and it should be obvious which one to use at any time. Like, using WSA for tags and PNC for functions would be fine, but using PNC for most functions and WSA for occasional special DSL functions would not be fine.
I've never seen a serious exploration of what WSA static dispatch would look like. I think that'd be worthwhile. It seems very possible that there could be a good solution.

Sam Mohr (Feb 07 2025 at 23:11):

5) is my hope for us to push on, it seems to be the final piece needed for decision making

Richard Feldman (Feb 08 2025 at 01:05):

I just got off a plane, and it looks like I missed a bunch of discussion! :sweat_smile:

Richard Feldman (Feb 08 2025 at 01:06):

I know I rarely do the explicit "this is the way forward" thing, but it seems like this is a case where we need a really clear decision, so:

Richard Feldman (Feb 08 2025 at 01:07):

let's plan for Roc 0.1.0 to support parens-and-commas calling, and not whitespace calling.

Richard Feldman (Feb 08 2025 at 01:08):

we've discussed this a bunch in the past, and although I and others have a lot of personal affection for whitespace calling, we're doing a rewrite and it just doesn't make sense to implement both from scratch.

Richard Feldman (Feb 08 2025 at 01:09):

of the two styles, it also doesn't make sense to me to choose whitespace calling as the one for 0.1.0

Richard Feldman (Feb 08 2025 at 01:12):

remember, 0.1.0 is not 1.0.0. I'm not saying we won't all look around after 0.1.0 and say "yeah this was a mistake." That can happen! We've had cases of trying out syntax in the past and then deciding not to stick with it after all.

I don't think that's going to happen with PNC, but I've made plenty of predictions that turned out to be wrong.

Richard Feldman (Feb 08 2025 at 01:14):

what I do know is that we have a very big, very exciting project that's just gotten underway, and I think it would be a mistake to redirect our energy into revisiting this design question that we've already spent a huge amount of time on.

Richard Feldman (Feb 08 2025 at 01:16):

I think what we should do is to commit to PNC for 0.1.0 and focus on lending an amazing compiler that people can try out!

Richard Feldman (Feb 08 2025 at 01:18):

there will always be time to revisit syntax options after we've already gotten a feel for how static dispatch and the other changes feel in the new compiler. :big_smile:

jan kili (Feb 08 2025 at 01:22):

I'm sad for a variety of reasons, but I respect your clarity and decisions. I'm willing to redirect my energy into helping us phase out these components smoothly!

Richard Feldman (Feb 08 2025 at 01:23):

thank you Jan, I know this is really important to you, and I really really appreciate it! :hearts:

jan kili (Feb 08 2025 at 01:24):

I have some ideas for next steps, but I'll give this thread time to breathe, if others want to weigh in.

Richard Feldman (Feb 08 2025 at 01:36):

Eelco Hoekema said:

In terms of feeling, it feels attracting new people from javascript world seems to be the main driver

as an aside, I've seen this a few times, and I want to note that this is not the main driver to me.

I didn't write that whole realworld code base thinking "I wonder how this would feel to a JavaScript programmer?" - I wrote it to see how I would personally feel using it, and I came away from that experiment feeling happy with how the syntax felt to use.

Is reclaiming strangeness budget one of the items on the list of benefits? Of course! Would I call it the "main driver" of the change? No.

As with so many other design questions, beginner-friendliness is one consideration among many.

Eli Dowling (Feb 08 2025 at 08:38):

Richard Feldman said:

let's plan for Roc 0.1.0 to support parens-and-commas calling, and not whitespace calling.

As I mentioned here: https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/reflecting.20on.20static.20dispatch/near/498415802
I think this would have been alleviated if, when the decision was made. There was more clarity as to why, and what alternatives had been considered and why they were rejected.

Yes, ofcourse folks can find that out by trawling through a few thousand messages spread across a number of zulip threads. But given this is a change a lot of people clearly feel pretty attached to, I think more clarity would be good.
Again, as I said in the last comment. It would also be a good thing from an externally facing perspective as a quick response when people don't understand why the change is happening.

Richard Feldman (Feb 08 2025 at 12:06):

totally fair! Just to clarify, this was the moment where I made the decision:

Richard Feldman said:

let's plan for Roc 0.1.0 to support parens-and-commas calling, and not whitespace calling.

it wasn't like I had a concrete plan and didn't say anything about it :big_smile:

Richard Feldman (Feb 08 2025 at 12:09):

I can put something together that explains the full motivation, but it might take me a bit. I need to be careful not to post something quick and unpolished, because the last time I did that it ended up on the front page of Hacker News and lobste.rs, and I'm still working through the backlog of responses to that. :sweat_smile:

Eli Dowling (Feb 09 2025 at 00:00):

hahaha, very true.

I guess mostly I just wanted to bring it up so it's in mind in future.
Personally I think it would be nice if meaningful changes to the language had a bit of a "final summary" drawn up before implantation. I think it would really help people who are only checking in occasionally to track how roc is evolving and also to record why things were decided for us to reflect on.

If module params and abilities get removed that would be a great case.

The lambda syntax change is another good example. I wasn't tracking that and was somewhat surprised by it.

I'm not suggesting a full on RFC or anything

More just:
This is why it felt needed:
These were the for and against/ alternatives.
This is why we decided on the outcome.

Ajai Nelson (Feb 09 2025 at 03:39):

As a person who’s been following Roc from the sidelines for a while, this seems like a good place to give my take. I feel similarly about this as I felt about the removal of backpassing. I liked backpassing and was a little sad to see it go. I liked whitespace application and am a little sad to see it go. But I also think this community (and Richard in particular) is good at making these kinds of decisions, and I trust you all to make a better decision than I would.

When it comes to syntax in particular, I’ve realized that although I have a lot of enthusastic opinions and preferences, at the end of the day, I like trying new languages. It’s unlikely that the syntax of a language would be what stops me from trying it. “Mainstream users” usually seem to have different preferences from me, and crucially, those preferences are more likely to affect whether they try the language. My understanding is that mainstream adoption is a goal for Roc.

I agree with @Eli Dowling that when it comes to these sorts of changes, having an explanation of why they were made really increases my trust. The explanation of why the compiler is being rewritten is actually a good example of that. Even though it’s “quick and unpolished,” it shows me that the decision was made thoughtfully. Seeing and hearing those kinds of explanations is what gives me the confidence that the decisions you all come to are probably the right ones for Roc.

Brendan Hansknecht (Feb 09 2025 at 06:05):

Yeah, I think one thing we have avoided is RFCs and the like. I think for many accepted ideas, they are small enough for this not to be important. For larger ideas, it is probably worth putting up an RFC or some other doc to explain the decision. Just something quick and as a reference

jan kili (Feb 09 2025 at 18:11):

JanCVanB said:

I have some ideas for next steps, but I'll give this thread time to breathe, if others want to weigh in.

Here are some ideas for next steps:

I'd like to resolve all WSA-related topics in Zulip.

jan kili (Feb 09 2025 at 18:12):

I'd like to start a topic for WSA deprecation planning.

jan kili (Feb 09 2025 at 18:14):

I'd like to start a topic for what to do about the |> operator.

Joshua Warner (Feb 09 2025 at 20:50):

For purely engineering reasons, we need to keep around some vestiges of WSA in the parser in order to properly parse WSA types, e.g. Result Str MyErrTy. A subset of those types also need to be represented as expressions as they're initially parsed, e.g. Foo a b in Foo a b : List (Result a b), since before we see the :, that could well be the start of an expression.

And at that point, we might as well keep around the ability to parse and format that generally.

Joshua Warner (Feb 09 2025 at 20:51):

FWIW, I'm in favor of keeping both WSA and |> around for a while, including implementing them in the new compiler. I think the community is split enough that it'll be beneficial to have both available for a while to play around with.