Pattern match multiple values · ideas

I just accidentally wrote something, and I am wondering if it would be useful syntax. Could it be possible to support comma separated values and pattern match on them, just as if they were in a tuple?

# What I wrote -- not valid syntax
when old, maybePrev is
    [], _ -> new

# What I meant to write -- valid syntax
when (old, maybePrev) is
    ([], _) -> new

Johan Lövgren (Dec 09 2023 at 08:16):

Agus Zubiaga (Dec 09 2023 at 12:53):

This could have the perf benefit of not allocating the tuple. Although, that seems something it could do anyway when it finds a tuple literal used with when.

Kilian Vounckx (Dec 09 2023 at 13:39):

In ocaml this would work as well, because tuples can be created without parentheses. There you can think of the comma as an operator for creating tuples with its own preference and associativity. I don't think we should go full ocaml here, but in cases like pattern matching I think it can be nice

Anton (Dec 10 2023 at 11:29):

I like it in the branch but I would keep the parenthesis in when (old, maybePrev) is.
If you try to parse when old, maybePrev is like it is a normal sentence you separate it into when old and maybePrev is. I think it's nice to have the tuple clearly indicated there, especially when you add function calls with space separated arguments after the when.

Richard Feldman (Dec 10 2023 at 11:58):

        a, b, c ->

        \a, b, c ->

in the first case, it now means a tuple, whereas in the second case it means function arguments

Kevin Gillette (Dec 11 2023 at 15:38):

I'm interested in the deeper distinction, but I could use more information to grok this properly... Is the concern that, if we were to accept this into the grammar, then:

If it's about learner confusion, rather than making the OP sample implicitly a match on tuples, what if we made clear that, just as a function accepts multiple arguments (and that they don't form a tuple), a match accepts multiple expressions (and that they also don't form a tuple). The distinction would be potentially be formal/academic, bc iiuc, wrapping the expression list in parens (or brackets) would semantically yield the same behavior, and potentially would be optimized into the same machine code.

Kevin Gillette (Dec 11 2023 at 15:42):

Alternatively, what if we just formally made function arguments an unnamed, unparenthesized tuple? I'm sure this has been discussed at length and need not be discussed here, but if it were workable, then it would be a different resolution to the confusion/inconsistency.

Eli Dowling (Dec 13 2023 at 22:45):

@Kevin Gillette I was going to say the exact same thing, I think there is a nice consistency between comma separated function args and comma separated match args. Neither are tuples and thus prevent unnecessary allocation.

Brendan Hansknecht (Dec 13 2023 at 22:49):

fn : (U8, U8, U8), U8 -> ...
fn = \(a, b, c), d ->

If we allow for the pattern matching syntax to include direct values as if they were tuples, you suddenly have to be able to parse:

fn : (U8, U8, U8), U8 -> ...
fn = \a, b, c, d ->

This is much less clear for the parser. We could theoretically special case this part of pattern matching just to the top level of when ... is, but currently a lot of that is shared implementation and features. That is at least my understanding.

Kevin Gillette (Dec 13 2023 at 22:53):

Kevin Gillette (Dec 13 2023 at 22:56):

technically wouldn't this be unambiguous though? iiuc, a top-level comma is not allowed in either the when condition or any of the match cases?

Brendan Hansknecht (Dec 13 2023 at 23:01):

I think it is unambiguous, just a question of consistent support of pattern matching and if certain versions add a lot of cases that we would prefer didn't exist...but yeah, I think that is small and it would be easy to special case this just for top level of a statement in a when is

Stream: ideas

Topic: Pattern match multiple values

Luke Boswell (Dec 09 2023 at 08:00):