[00:23:43] I basically agree, but then I think we really ought to have “general equality” as a built-in (so that list equality can work on untyped lists). If we get that, the current object equality could be refined to include equality of type. In any event, we now have Z16372, which distinguishes between Natural numbers and identities like Gregorian calendar months (but errors with [00:23:43] str [00:23:44] ings, types etc) (re @Toby: I still think we should split object equality so that we have one including a type checker, but if it's slow, it should hardly e...) [00:47:59] Yes, I can't immediately see a way of using that. Are you saying it's something I can already do/fix, or is there a bug to report? (re @Al: …actually, you can ignore the hackaround. It looks like this is conversion from the resulting integers into months.) [04:54:18] Thanks, I'm having trouble keeping track of what all these mean, and what depends on what. Are you saying that Z16380 depends on T363623? (re @Al: I basically agree, but then I think we really ought to have “general equality” as a built-in (so that list equality can work on ...) [06:53:15] I think it’s a bug. (re @Toby: Yes, I can't immediately see a way of using that. Are you saying it's something I can already do/fix, or is there a bug to repor...) [07:46:20] Not directly, no. Z16380 fails because Z6K1 is a simple string rather than an object (so its reification is not a list), and we can’t special-case strings efficiently enough to avoid a timeout (because we can’t peek at an object’s Z1K1 in case it’s a string, which would produce an error: T363623) (re @Toby: Thanks, I'm having trouble keeping track of what all these mean, [07:46:20] [07:46:20] and what depends on what. Are you saying that Z16380 depends on...)