Pattern Matching & String Fixes

[ghost]

Fixes pattern matching to work with the new string objects.

Also fixes a bug that caused an incorrect type error when the pattern handlers were of different types but with a common super type.

[kikofernandez]

I have looked at the PR and it seems fine. However, I would suggest to add a test that checks these two fixes.

[EliasC]

May I suggest two tests? :)

[kikofernandez]

sorry, a few nights without much sleep! +1

[ghost]

Tests added!

[kikofernandez]

@glundi I am pretty sure you know what test1, test2 and test3 do, but if you look at it from the outside, I have no clue of what you have solved or what you are testing. Could you provide, either a description of the thing that you are testing, or a test case name à la Python (long method name but descriptive to know what it does)? (I have no idea why test2 now prints the 123 outside the {})...

[ghost]

Oki, renamed the tests. I'm not sure why the checks suddenly fail now though. There doesnt seem to be anything new upstream for me to merge.

Edit: Nvm

[kikofernandez]

Is it expected to re-bind already bound variables (namely x) in the lhs of the match clause? How could I refer to the original value of x?

def valuaReBindBoundVariable(): void
  let x = 3 in
    match (4, 5) with
      (x, 5) => print("New bound value of x {}", x)
      _ => print("Nothing")

This example prints the value 4, when I would be expecting value 3.

[ghost]

There are two reasons for that design.

1. That's how it works in other languages.
2. If we later were to add matching on function heads, then re-binding makes a lot more sense.

[supercooldave]

@kikofernandez The inner x is a binding occurrence and it overrides the outer x. This is fairly standard lexical scoping. If you want to access the outer x, rename the inner x.

[kikofernandez]

@supercooldave yes, I know. It's the same in Haskell. I was wondering if we want to keep it that way. It seems like we want

[supercooldave]

@kikofernandez. I can't see the alternative being better. But I've been ruined by Haskell.

[ghost]

Well, Kikos interpretation would allow you to more easily match for equality against already defined variables. I.e. this:

let x = ... in
  match a with
    x => ...

instead of this:

let x = ... in
  match a with
    y when y == x => ...

[albertnetymk]

I didn't read PR, but I feel @glundi's first code example is the less surprising one. I would rather to see the first instead of the second.

[EliasC]

I definitely prefer the second one to the first one! This way you always get the same results from a variable pattern (bind a value to a name) instead of sometimes getting an implicit equality check.

[ghost]

The reason I prefer the second one is that it future proofs Encore for matching on function heads. Matching on function heads clearly should follow the same rules as regular matching (and would probably be implemented as some desugaring), functions should also behave the same regardless of how many heads they have.

  def foo(x)
    ..

Clearly x should introduce a new binding. Wouldn't it be confusing if it didn't also do so in this example as well?

  def foo(x, 0)
    ...
      foo(x, y)
    ...

If we pick the first interpretation in my previous post, then this second foo function should throw a run-time error whenever x already has a binding that is different from what we called foo with. Either that or we'll have a match expression that behaves by different rules in different circumstances. However, if we pick the second interpretation, then matching on function heads becomes much more intuitive.