Date: Thu, 27 Apr 2023 12:20:00 -0400
On Thu, Apr 27, 2023 at 12:03 PM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Wed, Apr 26, 2023 at 7:23 AM Andrew Tomazos via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Funnily enough, this exact syntax was considered when pattern matching was first discussed. There was a very lengthy discussion about whether to use switch or whether to use a new keyword (like inspect), and one of the ways that was suggested in the switch case was to use square brackets instead of parens to differentiate a pattern switch from a normal switch. The support for it was even considerable, but I think the inspect folks won out in the end.
>
>
> Interesting, this should have been reflected in the paper so others will be aware. In any case, this happened very early in the discussion and probably neither the requirements nor the developments were the same back then.
>
>>
>>
>> On Wed, Apr 26, 2023 at 12:38 PM Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>>
>>> On Mon, Apr 24, 2023 at 2:09 PM Михаил Найденов via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hello,
>>>> Here is a short proposal to re-use `switch` for Pattern Matching.
>>>
>>>
>>> Just so I'm clear. The argument is that introducing a new facility, with new semantics, under a new token (whether inspect or match) would be bad for teachability.
>>>
>
>>>
>>> So instead, you're proposing that we reuse an existing token (switch) to introduce two very different behaviors (statement vs expression, best match vs first match, fallthrough vs exactly one arm, integers vs more complex patterns, etc.), but since those different behaviors still need to be differentiated by the parser, you're proposing we do so by simply switching from parentheses to square brackets around the operand? And you're proposing that having 'switch' mean two very different things is better for teachability?
>
>
> That's the issue, it is not different semantically or functionally. Sure there are nuances, but there are not two different tools that one might choose one over the other for a particular reason.
>
> We must also consider the negatives by having two similar tools, the language already has a problem with that in many places, some of which going back to C like the many loops as an example.
>
> It seems also that the negatives of extending switch are speculative, where the overlap with switch is objective, more or less.
Is it, though? Or is it only "objective" based on your point of view?
Consider `for` vs. `while`. You can argue that it is "objectively
true" that `for` is just an offshoot of `while`. And yes, any `for`
loop could be stated as a variant of `while`. So maybe we don't need
the `for` keyword; it could have just been `while` with some
specialized parsing stuff in the parentheses.
But however much these things may be similar in actual function, we
don't *think* of them that way. When I have a range of indices that
you want to loop over, I don't even *consider* `while` as an
alternative solution. The correct answer is `for` because that's what
it's *for*. The syntax so directly matches its use cases that the more
generic form just isn't even a consideration.
While something might technically be implementable as something else,
you still have to look at the differences, particularly in how we
conceptualize problems and arrive at a particular solution. Whatever
functional overlap `switch` might share with `insepct`, it doesn't
share *conceptual* overlap. When people are having problems that
pattern-matching solutions would fix, they're not going to
conceptualize those problems as something that's "like switch".
They're going to conceptualize them as "pattern-matching problems" and
react accordingly.
As such, just like `for`, it deserves its own keyword.
> From the 4 points you made, I honestly can't think of one that is a problem in day to day use, with the last two actually being a desired positive.
>
> Last but not least, the problems of introducing a new keyword are not to be underestimated.
Why do you think they have been underestimated?
Also, I do find it a bit ironic. Previously, your proposals around
pattern matching were all (ostensibly) about making sure that it
shipped on time. But now, by re-openning a discussion that had
previously been closed, your suggestion could contribute to a delay.
> inspect (...) is basically guaranteed to be used as a function name in some code and will require some parsing ahead. `match` following the value will also be hard to do, especially in the case of multiple value (a, b, c, d) match.
>
> These are problems we create for ourselves out of nowhere, quite literally. Better, there is a real reason for that, not just worries.
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Wed, Apr 26, 2023 at 7:23 AM Andrew Tomazos via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> Funnily enough, this exact syntax was considered when pattern matching was first discussed. There was a very lengthy discussion about whether to use switch or whether to use a new keyword (like inspect), and one of the ways that was suggested in the switch case was to use square brackets instead of parens to differentiate a pattern switch from a normal switch. The support for it was even considerable, but I think the inspect folks won out in the end.
>
>
> Interesting, this should have been reflected in the paper so others will be aware. In any case, this happened very early in the discussion and probably neither the requirements nor the developments were the same back then.
>
>>
>>
>> On Wed, Apr 26, 2023 at 12:38 PM Barry Revzin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>>
>>> On Mon, Apr 24, 2023 at 2:09 PM Михаил Найденов via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>>
>>>> Hello,
>>>> Here is a short proposal to re-use `switch` for Pattern Matching.
>>>
>>>
>>> Just so I'm clear. The argument is that introducing a new facility, with new semantics, under a new token (whether inspect or match) would be bad for teachability.
>>>
>
>>>
>>> So instead, you're proposing that we reuse an existing token (switch) to introduce two very different behaviors (statement vs expression, best match vs first match, fallthrough vs exactly one arm, integers vs more complex patterns, etc.), but since those different behaviors still need to be differentiated by the parser, you're proposing we do so by simply switching from parentheses to square brackets around the operand? And you're proposing that having 'switch' mean two very different things is better for teachability?
>
>
> That's the issue, it is not different semantically or functionally. Sure there are nuances, but there are not two different tools that one might choose one over the other for a particular reason.
>
> We must also consider the negatives by having two similar tools, the language already has a problem with that in many places, some of which going back to C like the many loops as an example.
>
> It seems also that the negatives of extending switch are speculative, where the overlap with switch is objective, more or less.
Is it, though? Or is it only "objective" based on your point of view?
Consider `for` vs. `while`. You can argue that it is "objectively
true" that `for` is just an offshoot of `while`. And yes, any `for`
loop could be stated as a variant of `while`. So maybe we don't need
the `for` keyword; it could have just been `while` with some
specialized parsing stuff in the parentheses.
But however much these things may be similar in actual function, we
don't *think* of them that way. When I have a range of indices that
you want to loop over, I don't even *consider* `while` as an
alternative solution. The correct answer is `for` because that's what
it's *for*. The syntax so directly matches its use cases that the more
generic form just isn't even a consideration.
While something might technically be implementable as something else,
you still have to look at the differences, particularly in how we
conceptualize problems and arrive at a particular solution. Whatever
functional overlap `switch` might share with `insepct`, it doesn't
share *conceptual* overlap. When people are having problems that
pattern-matching solutions would fix, they're not going to
conceptualize those problems as something that's "like switch".
They're going to conceptualize them as "pattern-matching problems" and
react accordingly.
As such, just like `for`, it deserves its own keyword.
> From the 4 points you made, I honestly can't think of one that is a problem in day to day use, with the last two actually being a desired positive.
>
> Last but not least, the problems of introducing a new keyword are not to be underestimated.
Why do you think they have been underestimated?
Also, I do find it a bit ironic. Previously, your proposals around
pattern matching were all (ostensibly) about making sure that it
shipped on time. But now, by re-openning a discussion that had
previously been closed, your suggestion could contribute to a delay.
> inspect (...) is basically guaranteed to be used as a function name in some code and will require some parsing ahead. `match` following the value will also be hard to do, especially in the case of multiple value (a, b, c, d) match.
>
> These are problems we create for ourselves out of nowhere, quite literally. Better, there is a real reason for that, not just worries.
Received on 2023-04-27 16:20:13