Behavior of pattern mathing on objects

On Wed, Sep 21, 2011 at 10:00 PM, Jeff Olson wrote:
> Let
>
>   val s: Seq[Nothing] = Vector.empty
>
> Now I grok that s == Nil even though s ne Nil and s.getClass != Nil.getClass
> .
>
> This morning I would've bet money that
>
>   s match { case Nil => true ; case _ => false }
>
> returns false. I would've lost that bet. I would've lost even more money
> when I bet that
>
>   s match { case _: Nil.type => true ; case _ => false }
>
> surely returns false. At least
>
>   s match { case x if x.isInstanceOf[Nil.type] => true ; case _ => false }
>
> returns false!!
>
> At little poking around revealed that pattern matching on case objects (but
> not case classes) is unbelievably implemented in terms of equality!!! I can
> override equals to my heart's content on case classes and not affect pattern
> matching but the same is apparently not true for case objects. This seems
> like a serious bug to me.
>
> If this is by design then can someone explain this:
>
> scala> s match { case _: List[_] => false ; case Nil => true }
> :9: error: unreachable code
>               s match { case _: List[_] => false ; case Nil => true }
>                                                                ^
>
> I agree that that code should be unreachable, but, in fact, it seems that is
> reachable.
>
> In my view, an expression x should match a case object Foo if and only if
> Foo eq x . Always and without exception. Why is this not the case?
>

It has to do with the pattern classifications. X is a constant
pattern, it does not matter whether it refers to a case object or some
other value. Now, for other values, clearly equality wrt == is the
right way to specify matching patterns.
I am not sure whether we should complicate the spec to single out case
objects from other objects in pattern matching. Your arguments are
convincing, but generally I have come to realize that complicating the
spec often creates other, equally strange borderline cases, so that,
in the end, simple rules are preferable.

Cheers

https://issues.scala-lang.org/browse/SI-4577

"pattern matcher, still disappointing us at equality time"

On Wed, Sep 21, 2011 at 1:00 PM, Jeff Olson wrote:
>   s match { case _: Nil.type => true ; case _ => false }

This one should be false. It's in the ticket.

On Wed, Sep 21, 2011 at 1:00 PM, Jeff Olson wrote:
> In my view, an expression x should match a case object Foo if and only if
> Foo eq x . Always and without exception. Why is this not the case?

Oh, and that's definitely not happening. There was an epic thread
between spoon and drmaciver like three years ago about this, you
should dig it up. User-defined equality for pattern matching is
useful, even though it can have interesting consequences, including
thrill rides like https://issues.scala-lang.org/browse/SI-1503 .

I find the behaviour/semantics of pattern matching vague and
struggling with it too.

I think the confusion starts with what a pattern exactly is. Is a
pattern some kind of an expression or something different (a signature
of the constructor I guess which is calculated and fixed in compile-
time, but evaluated against in run-time)? If you use an object as
pattern then it is not really that object, but probably its signature,
so the behaviour of 'equals' is not relevant.
Basically pattern matching is matching a value against a signature
while equals is matching two values.
In the Language Specification a pattern is treated separately (correct
me if I am wrong).

I think most people for simplicity will interpret:

s match {
case Nil => true
case _ => false
}

as:

if(s == Nil) true
else false

While the first is a comparison between an identifier and a pattern
and the latter is a comparison between an identifier and an expression
so the two semantics are really fundamentally different. Even if the
result can be sometimes the same in practice, the way it works is
different. An identifier can be replaced with an expression with the
same return value and return type and it would work the same, but a
pattern cannot be replaced by an expression although some patterns
(like numbers) look like an expression.

I had forgotten about constant patterns. I see the problem now.

I have the utmost respect for those who write language specs and the difficulties they encounter, and I agree with you wholeheartedly that simple rules are preferable to long lists of exceptions. However, in this case it seems that the pattern Nil can be interpreted in two ways (as a constant-like pattern or a case-like pattern) and that an exception must be made one way or the other. Which is simpler depends on how you write the spec. One should also go by the rule of least surprises. I think that when programmers are comfortable with case classes they will expect case objects to behave in a similar manner--it didn't even occur to me to think of Nil as a constant pattern.

Spec problems aside there are very real practical problems with how things currently work. Since pattern matching on a case object invokes equality, if a custom equality method (most likely inherited) is defined in terms of pattern matching a infinite loop will result. So everyone who writes a case object may have to write silly boilerplate equality code to break out of the loop (as is currently done in Nil). Not to mention the minor performance penalty that comes from having to do a equality method call every time someone writes { case Nil => ... }

One last point before I rest my case (for now anyway): What currently is the difference between a case object and an non-case object? After all they appear to behave exactly the same in pattern matching. Okay, a case object gives you a nice toString and stable hashCode, but that seems to be about it. Isn't it reasonable to expect that case objects will behave differently, certainly more efficiently, in pattern matching than ordinary objects? Isn't that the whole point of case thingies?

-Jeff

I did see the thread you mention, although I have yet to tackle it entirely (perhaps someone would be kind enough to summarize). The issue you pointed to led me to another curious discovery

scala> s match { case Nil => true ; case _ => false }
res8: Boolean = true

scala> s match { case x@Nil => true ; case _ => false }
res9: Boolean = true

scala> s match { case x@Nil => {x; true} ; case _ => false }
res10: Boolean = false

It would appear that a pattern match is affected by the presence of a binding and whether or not that binding is used on the right-hand side of the case statement. Now I understand why the presence of a binding must affect the match (though it seems very ugly and unfortunate), but surely its usage (or lack therein) on the RHS should not affect the match. That said I'm not sure how this should behave

scala> s match { case _@Nil => true ; case _ => false }

Does a binding exist or not?

Finally, to your point about the usefulness of user-defined equality in pattern matching: I'm not in anyway disputing this. I'm simply saying that user-defined equality should never affect the pattern matching behavior of case objects (just as for case classes).

On Thu, Sep 22, 2011 at 1:04 PM, Jeff Olson wrote:
> I did see the thread you mention, although I have yet to tackle it
> entirely (perhaps someone would be kind enough to summarize).

Summary: "it's complicated." I think you should read it, because you
sound like you could help me improve the pattern matcher spec, which is
help I could really use, but to do so you need to appreciate the range
of competing concerns.

> It would appear that a pattern match is affected by the presence of a
> binding and whether or not that binding is used on the right-hand side
> of the case statement. Now I understand why the presence of a binding
> must affect the match (though it seems very ugly and unfortunate), but
> surely its usage (or lack therein) on the RHS should not affect the
> match.

https://issues.scala-lang.org/browse/SI-5024

> That said I'm not sure how this should behave
>
> scala> s match { case _@Nil => true ; case _ => false }
>
> Does a binding exist or not?

Yes. In general _ is just a name you can't refer back to.

I'm working my way through that thread, and I'll be happy to offer you more feedback when I'm done.

I agree with your interpretation of the pattern _@Nil, although on careful inspection of the spec, I note that it's not strictly permitted by the grammar. Though perhaps it should be given that it would have different matching semantics than the pattern Nil. If it's not going to be allowed than it shouldn't compile.

(BTW: It would be nice if there were a machine readable version of the grammar available somewhere. I've found numerous typos, omissions, and redundancies in the version included in the PDF spec).

-Jeff

On Fri, Sep 23, 2011 at 8:28 PM, Jeff Olson wrote:
> (BTW: It would be nice if there were a machine readable version of the
> grammar available somewhere. I've found numerous typos, omissions, and
> redundancies in the version included in the PDF spec).

It would be nice, yes. My collection of sentences which start that
way is impressively large. (But of course a lot of it is boilerplate,
because they all start "It would be nice...")