Add `"pattern"` scope type

[wenkokke]

I propose we add a scope type for the patterns in pattern matches, which are very important in functional languages like Haskell, Scala, and Rust, and increasingly important in languages such as JavaScript (see tc39) and Python (see pep 636).

// TypeScript
function fst<A, B>(tup: [A, B]) {
  const { x, y } = tup;
  //    ^^^^^^^^
  return x;
}
// Using tc39
function fst<A, B>(tup: [A, B]) {
  match (tup) {
    when ({ x, y }): return x;
    //    ^^^^^^^^
  }
}

# Python
def fst(tup):
  match tup:
    case (x, y): return x
#        ^^^^^^

// Scala
def fst[A, B](tup:  (A, B)): A =
  tup match {
    case (x, y) => x
    //   ^^^^^^
  }

-- Haskell
fst :: (a, b) -> a
fst (x, y) = x
--  ^^^^^^

// Rust
fn fst(tup: (A, B)) {
  match tup {
    (x, y) => x
//  ^^^^^^
  }
}

Patterns are different from conditions. The easiest way to show this is by implementing the if then else construct using patterns.

def ifThenElse(cond, ifTrue, ifFalse):
  match cond:
#       ^^^^  <-- "condition"
    case True:
#        ^^^^  <-- "pattern"
      return ifTrue()
    case False:
#        ^^^^^  <-- "pattern"
      return ifFalse()

Patterns are not adequately covered by branches, since "branch" selects the entire branch, which may match on multiple patterns.

and ::  Bool -> Bool -> Bool
and True True = True
--  ^^^^^^^^^^^^^^^^  <-- branch
--  ^^^^  <-- pattern
--       ^^^^  <-- pattern
and _    _    = False
--  ^^^^^^^^^^^^^^^^^ <-- branch
--  ^  <-- pattern
--       ^  <-- pattern

This makes it impossible to use "branch" to select, e.g., the first pattern in the second branch.

See related issues #579 and #1174.

[wenkokke]

@pokey wrote here that the patterns should be addressed by "name", "key", or "condition".

I've argued above that "condition" should refer to the "subject" and that its use for patterns is confusing.

The complexity of patterns makes it rather odd to refer to them by "name" or "key". That suggestion may have been due to the overly simplistic nature of the examples. For instance, see the following Haskell program, where I've annotated the top-most patterns. At very least, I hope that shows that "name" is inadequate?

someFunction x (y1 : y2 : ys) (a, b, (c, [d])) = rhs
--           ^  ^^   ^^   ^^   ^  ^   ^   ^    <-- names
--           ^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ <-- top-level patterns
--              ^^   ^^^^^^^   ^  ^^^^^^^^^^^  <-\ 
--                   ^^   ^^      ^  ^^^^^^^^  <-| sub-patterns
--                                    ^  ^^^   <-|
--                                        ^    <-/

Note: The program looks contrived, due to the fact I've copied it from a parser test, but patterns like these are extremely common in Haskell. Sometimes they use better names.

[pokey]

my thinking would be

someFunction x (y1 : y2 : ys) (a, b, (c, [d])) = rhs
--           ^ ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ <-- "arg"
--              ^^   ^^   ^^   ^  ^  ^^^^^^^^  <-\
--                                    ^  ^^^   <-| "item"
--                                        ^    <-/

[wenkokke]

I'm not sure if item makes sense in the general case?

either                  :: (a -> c) -> (b -> c) -> Either a b -> c
either f _ (Left x)     =  f x
either _ g (Right y)    =  g y

Are the x and y on the left hand side still item?

[wenkokke]

@pokey What do you think should be used in the JavaScript, Python and Rust examples?

[wenkokke]

These aren't value because they're binding occurrences rather than values, so the use cases, domain and iteration scopes are very different.

These aren't key or item because they're not always in a list or map like context, and furthermore because they're binders rather than items in a list.

[pokey]

I'm not sure if item makes sense in the general case?

either                  :: (a -> c) -> (b -> c) -> Either a b -> c
either f _ (Left x)     =  f x
either _ g (Right y)    =  g y

Are the x and y on the left hand side still item?

no I think I'd call those "arg"?

[pokey]

we tend to use the same scope name whether it's constructing or deconstructing. makes it easier for the ol' lizard brain that just sees shapes

[pokey]

@pokey What do you think should be used in the JavaScript, Python and Rust examples?

I believe they're as follows, but easiest to paste them into a file, pull up the "bar cursorless" sidebar and click through the scopes to see what hits. Tho I'm guessing we don't support the tc39 one

// TypeScript
function fst<A, B>(tup: [A, B]) {
  const { x, y } = tup;
  //    ^^^^^^^^  <~~ name
  return x;
}
// Using tc39
function fst<A, B>(tup: [A, B]) {
  match (tup) {
    when ({ x, y }): return x;
    //    ^^^^^^^^ <~~ condition
  }
}

# Python
def fst(tup):
  match tup:
    case (x, y): return x
#        ^^^^^^ <~~ condition

[wenkokke]

I'm not sure if item makes sense in the general case?

either                  :: (a -> c) -> (b -> c) -> Either a b -> c

either f _ (Left x)     =  f x

either _ g (Right y)    =  g y

Are the x and y on the left hand side still item?

no I think I'd call those "arg"?

So it's nested args all the way down? Because (Left x) is also "arg".

[pokey]

So it's nested args all the way down? Because (Left x) is also "arg".

In this case, yes, but note that in https://github.com/cursorless-dev/cursorless/issues/2177#issuecomment-1898749525 there's no "arg" nesting

[wenkokke]

True, but item is inappropriate there, so those cases would also be "arg".

[pokey]

item is inappropriate there

can you elaborate?

[wenkokke]

item is inappropriate there

can you elaborate?

If

foo x = undefined
--  ^ arg

and

foo (Left x) = undefined
--        ^ arg

then

foo (x : xs) = undefined
--   ^ arg

and

foo [x] = undefined
--   ^ arg

because they're all the same kind of thing.

[wenkokke]

One major use case for this, the overlapping iteration scopes between formal and actual arguments, might be fixed by separating @argument.formal and @argument.actual:

--            vvv argument.actual.iteration
--              v argument.actual
--            v argument.actual
--          v argument.actual
foo f x y = f x y
--  ^ argument.formal
--    ^ argument.formal
--      ^ argument.formal
--  ^^^^^^^^^^^^^ argument.formal.iteration

[pokey]

interesting. maybe let's discuss this one in meet-up?