Matthias Toepp (Apr 24 2023 at 05:48): Matthias Toepp (Apr 24 2023 at 05:48):IDEA:
if with when..is syntax.BENEFITS:
Enhance the feeling of consistency when using roc's decision structures:
else as the last branch of all decision structures will feel more consistentif..else and when..is would change to look/feel/handle in much more the same way.Make roc feel more conventional AND intuitive AND robust, by having else at the end of decision structures, including at the end of when..is:
else is both more conventional and more intuitive than _->.else is more visible and feels more robust than "_->".Make roc cleaner in terms of noise & alignment (with the proposed multi-branch Boolean structure)
else if and before then).else..if structure.Enhanced refactorability:
Enhanced diff.
if to else if - so changes there would probably be more accurate in regards to version control diffs. (quoting @Georges Boris )This syntax may help to ease people into learning pattern matching, as the parallels to a multi-branch boolean structure are more apparent when the syntaxes are more similarly laid out.
THE PROPOSED SYNTAX:
# `when..is`: multi-line branching on pattern matching:
size =
when x is
Small ->
"small"
Medium ->
"medium"
else # note use of else is similar to next example.
"large"
# `when`(used alone): multi-line branching on boolean expressions:
size =
when
x < 10 then
"small"
x < 100 then
"medium"
else # note use of else is similar to prev. example.
"large"
# single line use:
# refactors nicely to the above.
size =
when x < 10 then "small" else "large"
DISADVANTAGES:
More unusual to people who have already learned another language with if..else syntax.
if..else expressed this way moves you part-way towards understanding pattern matching syntax in terms of something that you already understand.Requires an extra level of indentation for multiline syntax.
Anton (Apr 24 2023 at 08:45):I have some doubts about unifying when and if, it may actually prevent confusion to have a clear distinction between when you're working with booleans vs doing other pattern matching.
Matthias Toepp (Apr 24 2023 at 15:15):yes, fair enough,
i was thinking...
The when on it's own looked quite distinctive from when..xxxx..is and less of something floating in the air than if in that position.
The then following the condition further signifies this boolean expression matching.
For a beginner who is already comfortable with if..then..else if..then..else, certainly there must be some extra feeling of confusion with new syntax... (the 2nd disadvantage I listed)
...BUT considering that pattern matching would be much more strange and has the same shape as the proposed syntax...
...This very point is also an upside. Seeing the if..else expressed in the when format moves people part-way towards becoming familiar with the formatting of pattern matching syntax in terms of something that they already understand. So it serves as an easier midway point towards what will likely be strangeness of pattern matching syntax.
Nonetheless as I say there is truth to what you are saying.
(Of course if we stick with what we have we don't get the benefits listed above either.)
Brendan Hansknecht (Apr 24 2023 at 15:31):I think something like this syntax is totally reasonable, but I think it falls into the weirdness budget. I think it would confuse beginners and make the language feel stranger at first. Why doesn't the language have if would probably become a top faq.
Anton (Apr 24 2023 at 15:33):...BUT considering that pattern matching would be much more strange and has the same shape as the proposed syntax...
I actually would expect pattern matching to be easy to understand, even for someone who is new to programming. This example seems very intuitive:
when stoplightColor is
Red -> "red"
Green -> "green"
Yellow -> "yellow"
The new syntax would also introduce new inconsistencies:
when x is\n and when\n-> or then or else I believe that these changes lead to a general increase in complexity for beginners.
Matthias Toepp (Apr 24 2023 at 15:36):Yup, programmers knowledge form previous languages forms a kind of legacy constraint. There is pressure on us to have backwards compatibility with that knowledge, and justifiably so. However, this results in a force that opposes improvement.
Anton (Apr 24 2023 at 15:38):However, this results in a force that opposes improvement.
Agreed, balancing this is hard
Matthias Toepp (Apr 24 2023 at 15:40):"I believe that these changes lead to a general increase in complexity for beginners."
Yes but it is obviously simpler as well.
Matthias Toepp (Apr 24 2023 at 15:45):I truly hope this exhausts my efforts to try to innovate on this front!!!!!! :smile:
Anton (Apr 24 2023 at 16:20):I sense that you are frustrated because you've put a lot of effort into writing up many ideas and we've been quite critical, is that correct?
I'm sorry that you feel that way, we truly want to make contributing to roc enjoyable, friendly, and welcoming.
I see our zulip chat quite like an "idea lab" as described by Tim Urban: "a safe space for people, a dangerous space for ideas.".
This twitter thread offers some nice context.
2 kinds of intellectual culture: Idea Lab: a safe space for people, a dangerous space for ideas. Echo Chamber: a safe space for a sacred set of ideas and people who express them, a dangerous space for opposing ideas and people who express them.
- Tim Urban (@waitbutwhy)This type of discussion can sometimes be uncomfortable, especially because it's common to have experienced situations earlier in life where others treat you worse based on your ideas.
Because I want to be productive and move things along I think I'm sometimes a little too direct when voicing my opinions.
To test whether an idea is good, it does need to stand up to being challenged. Similar to boxing, there's no way to determine the strength of a boxer if they've never fought anyone.
@Matthias Toepp I'd like to hear your thoughts on how we could have handled this situation better :heart:
Matthias Toepp (Apr 24 2023 at 18:59):Thanks @Anton! :smile: I truly appreciate the sentiment!
It is extremely interesting to me how ideas are shaped and adopted in roc's community and society in general.
I imagine it would be frustrating for me if I could not appreciate why you and others are challenging my thinking, but so far everything everyone has said has all seemed quite valid and appreciated on my end.
When I said...
I truly hope this exhausts my efforts to try to innovate on this front!!!!!! :smile:
I just said that because...
On one hand the issue of having a cond-like structure that incidentally seems to offer some side-effect benefits (such as else being used in when..is) has a strong appeal to me.
On the other hand it is also not the absolutely most important thing, and yet, time resources (mine and others) spent on this are accruing.
I really appreciate all the ways you and everyone else has challenged the ideas put forward (on this thread and the related ones).
I feel quite at peace with having explored the possibilities fairly thoroughly and as a result now having a better sense of the opportunities and the tradeoffs of cond-like syntax. I feel wiser for the engagement. The process has been successful from my point of view!
Matthias Toepp (Apr 24 2023 at 18:59):Emerging form these conversations, if I have any concern it's that I don't see how a conversational approach, like this, necessarily facilitates convergence of the community based on an evaluation of the balance of the weighted benefits vs. weighted disadvantages. (Exaserbated by people's limited time to investigate the pros and cons of a proposal).
If some number of perceived disadvantages are voiced, along with some number of advantages then it is still an unresolved question of how the disadvantages weigh against the advantages for the project, and that seems hard to assess when what we mainly have is people pointing out specific benefits or concerns.
Matthias Toepp (Apr 24 2023 at 19:51):I suspect that I'm just seeing the limitations of a messaging app in helping a community to collectively weigh the pros and cons of an idea.
Anton (Apr 25 2023 at 09:12):I'm glad we could talk this through :)
Decision-making with a large group is hard, you're welcome to share suggestions for improvements.
I find this process interesting as well, innovation in this area could deliver a lot of value because long and time-consuming conversations are common in open source projects. This type of conversation regularly has branches or subconversations about specific topics and it would be nice to have interface that makes it easy to navigate these branches and perhaps close branches after they've been resolved.
Back to the matter at hand; I don't think a proposal should be approved when:
For the new if syntax there has been positive sentiment expressed by multiple people so there we can move on to the next stage; I'll continue the conversation there.
Matthias Toepp (Apr 25 2023 at 13:34):I guess you must mean this thread: https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/adjust.20meaning.20of.20else
Matthias Toepp (Apr 29 2023 at 22:39):I just happened to notice that the proposed syntax is similar to kotlin:
Matthias Toepp (Apr 29 2023 at 22:41):From https://learnxinyminutes.com/docs/kotlin/
"if" can be used as an expression that returns a value.
For this reason the ternary ?: operator is not needed in Kotlin.
*/
val num = 5
val message = if (num % 2 == 0) "even" else "odd"
println("$num is $message") // => 5 is odd
// "when" can be used as an alternative to "if-else if" chains.
val i = 10
when {
i < 7 -> println("first block")
fooString.startsWith("hello") -> println("second block")
else -> println("else block")
}
// "when" can be used with an argument.
when (i) {
0, 21 -> println("0 or 21")
in 1..20 -> println("in the range 1 to 20")
else -> println("none of the above")
}
// "when" can be used as a function that returns a value.
var result = when (i) {
0, 21 -> "0 or 21"
in 1..20 -> "in the range 1 to 20"
else -> "none of the above"
}
println(result)
Last updated: Jun 16 2026 at 16:19 UTC