# Check-eq? not behaving properly in Typed Racket

**URL:** <https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327>\
**Category:** Questions & Answers\
**Created:** [September 20, 2023, 2:55pm UTC](https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327 "2023-09-20T14:55:39Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![shawnw](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/shawnw/32/1031_2.png) [@shawnw](https://racket.discourse.group/u/shawnw)\
**Post date:** [September 20, 2023, 2:55pm UTC](https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327/1 "2023-09-20T14:55:39Z")

</div>

Consider:

```scheme
#lang typed/racket/base

(require typed/rackunit)

(: hash->immutable-hash (All (k v) (-> (HashTable k v) (Immutable-HashTable k v))))
(define (hash->immutable-hash htab)
  (if (immutable? htab)
      htab
     '(more code here)))

(define h '#hasheq((a . 1) (b . 2) (c . 3)))
(eq? (hash->immutable-hash h) h) ; => #t
(check-eq? (hash->immutable-hash h) h) ; Fails.

```

Basically, if passed an immutable table, it's returned, otherwise it creates a new immutable table with the same contents as the original.

When testing the "return the argument if already immutable" case, I can't figure out why `check-eq?` fails when the equivalent `eq?` succeeds.  
The same test case passed in an standard untyped Racket implementation; it's just in TR that there's a problem.

---

<div class="post-metadata">

**Author:** ![bakgatviooldoos](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/bakgatviooldoos/32/1381_2.png) [@bakgatviooldoos](https://racket.discourse.group/u/bakgatviooldoos)\
**Post date:** [September 20, 2023, 5:32pm UTC](https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327/2 "2023-09-20T17:32:02Z")

</div>

Hi, @shawnw.

I can't really comment on the _why_, but it seems like it is a [known issue](https://groups.google.com/g/racket-users/c/6u0VdBUipnc/m/l2Q3t4ZEAwAJ), at least, that Typed Racket and RackUnit don't play well together in this regard.

Sorry for the nothingburger.

---

<div class="post-metadata">

**Author:** ![shawnw](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/shawnw/32/1031_2.png) [@shawnw](https://racket.discourse.group/u/shawnw)\
**Post date:** [September 20, 2023, 6:01pm UTC](https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327/3 "2023-09-20T18:01:06Z")

</div>

An eight year old thread and the issue is still there, yay. `(check-true (eq? ... ...))` seems to work though.

---

<div class="post-metadata">

**Author:** ![EmEf](https://avatars.discourse-cdn.com/v4/letter/e/53a042/32.png) [@EmEf](https://racket.discourse.group/u/EmEf)\
**Post date:** [September 20, 2023, 6:52pm UTC](https://racket.discourse.group/t/check-eq-not-behaving-properly-in-typed-racket/2327/4 "2023-09-20T18:52:12Z")

</div>

The explanation is simple. The types compile to contracts before values escape to untyped code, possibly a library. Some contracts wrap values in a way that obscures pointer equality.

I bumped into this issue myself over the summer when I created a TR benchmark from a little project I wrote. I went back and questioned why I used `eq?` and not `equal?` -- @robby 's old question from our 2004 paper. No I didn't need to use `eq`.