On Mar 5, 2021, at 8:29 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
>>
>> The one objection I still have to grobble is one I've raised before: it
>> makes it hard to imagine ever representing disjunctions as guards. I always
>> bring up stuff like
>>
>> switch (people) {
>> case Pair(Person(String name1, int age1), Person(String name2, int age2))
>> | age1 > age2 -> name1 + " is older"
>> | age2 > age1 -> name2 + " is older"
>> | otherwise -> format("%s and %s are the same age", name1, name2)
>> }
>>
>
> If we can assume that such "sub-switches" are routinely total on the top
> pattern, I think we can do this with the tools on the table, perhaps with
> some small adjustments.
I’m going to blow Brian’s cover here, but then explain why
it’s a good cover.
When I read Alan’s note I thought, “he wants continue-switch
for partial sub-cases”. We should note that this on the table,
but on a side-table, sidelined with many other low-priority
high-cost features.
(A “sub-case” is some form of case which refines a preceding
case. Haskell allows this in the form of |-guards. It’s a nice
idea, sometimes. We could bike-shed it in many ways.)
By “continue-switch” I mean a variant of “continue” which
breaks out of the current case and proceeds to the next
applicable case, if any, exactly and precisely as “continue”
in a loop breaks out of the current iteration and proceeds
to the next iteration, if any. I would paint it “continue switch”
which then begs the question of whether this is a generative
construct (as the linguists might say) calling for “continue K”
for K in switch, for, while, do, and (yes!) if. If switch refactors
to an if-chain, why then continue-switch would refactor to
continue-if, which turns out to branch to the next “else”,
if any.
All that is to say, nobody should be surprised that we are
keeping this on the low-priority list, because its specification
cost would seem to be higher than its occasional utility.
— John
