> The easiest thing to do is to treat negative numbers as positives with unary negation and repair that tree rapidly in the parser. So you end up with something like a constant folded integer in the stream which is indistinguishable from an integer literal anyway. As I tried to tersely explain in #2, I believe that is exactly what happens in today's implementation. > However, there's a glitch ... There's a bunch of ways to do this. My limited testing of boundary cases shows them handled sensibly. Whether it is always optimal in some cosmic sense, I do not know. Or care because I am skeptical about and unsympathetic toward people who try to fill 63-bit integers and play games with negation. If their poking results in some extra opcodes, I will have a hard time hearing any complaints on that. > None of this belongs in the document :D You'll get no argument against that from me. > You could take the position in the documents that the system behaves as though numeric literals could be negative and call it good. The documentation is all about how the system behaves without looking into the black box doing the behaving. Except for the technical implementation docs. For those, an as-if description would be just sad. > I wouldn't blame you... the details above make interesting trivia but poor documentation. I would shed any blame like that quickly, for just that reason.