@sydney.lambda

When you bind arg-type to (external-form->type ty), that expression is run immediately so that when you pass arg-type to the other places, you’re passing in its value (call-by-value like you said, rather than call-by-name or some other evaluation strategy).

Essentially the expression is reduced to the normal form (int), but that isn’t quite a precise way to represent the normal form at play here. If you run (int) twice, you get results that aren’t eq?, but if you run arg-type twice, they are eq?. That’s because the expression (int) performs a side effect (allocation of a fresh eq? identity), and arg-type is bound to the result of that side-effectful operation.

I believe there is no Racket syntax for expressing what the true content of a value is, complete with its eq? identity. (That graph notation comes close.) Instead, a lot of Racket code treats the eq? identity as an accident of the implementation details of the code, and it pays attention to that identity mainly when it’s implementing some kind of fast-path optimization where there’s still an equivalent slow path with the same result. So soegaard2’s recommendation to reconfigure the way you’re displaying values with print-graph is a good one; that way you don’t have to meticulously control which values in the output are eq?.

@rokitna thank you for that explanation! that seems to be just what I needed clearing up. That creating a new instance of a struct has the side-effect of allocating a fresh eq? identity was not something I had taken into consideration. If all ints were not “the same”, I think this would have stood out more obviously to me, if that makes sense.

Chaperones and impersonators play a part as well. Two objects can have the same “identity” without being eq?. A vector and a chaperone of that vector for example. Mutate one and you mutate them both, but they’re not eq? values