document nit chapter 2 section 3 literals
(1) By Rico Mariani (rmariani) on 2021-07-20 01:51:14 [link]
Literals cannot be negative according to the diagram. There are good reasons for this actually. However the discussion talks about negative literals. I suspect what's going on is that the negation operator is applied to the constant literal pretty early on in the processing creating a constant negative number which is the next best thing to a literal. You have various choices for how to resolve this: * do nothing, most people won't even notice or care * add the possibility of negative integer literals which is sort of a lie but does help to explain the rules for when negative integers promote to floating point * leave the diagram alone but mention that they are going to be combined with unary negation very quickly and at that time these rules will apply * do the above in a footnote I wouldn't blame you if you choose the do nothing option if only for brevity. Maybe leave the extra details in a comment to documenters.
(2) By Larry Brasfield (larrybr) on 2021-07-20 02:56:26 in reply to 1
The discussion following the diagram on [numeric-literal](https://sqlite.org/lang_expr.html#litvalue) values is inconsistent with the diagram. So some repair is appropriate. It is interesting that the scanner does not recognize (or return) negative reals or integers. That is handled, apparently (at first examination, which is enough for this discussion) by the parser. Whether the parser takes care of negative literals or that is done during semantic analysis and optimization is immaterial. The fact is that the [VDBE](https://sqlite.org/opcode.html) produces identical opcodes when either positive or negative numbers are used.<sup>1</sup> So, for all practical purposes, the library acts **just as if** one can write negative numeric literals. And so it is certainly best (IMO) for the docs to indicate as much. There is no confusion awaiting users that way, and possibly a reduction of confusion for those who take the railroad charts too literally. ---- 1. Of course, the constant loaded into a register by the instruction differs, but the opcode is not to be confused with its parameters.
(3) By Rico Mariani (rmariani) on 2021-07-20 03:49:46 in reply to 2 [link]
It turns out all kinds of weirdness ensues if you try to do negatives with lexemes. This "beast" becomes hard to parse ``` 5-3 ``` because it lexes as two numbers... 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. However, there's a glitch. You can represent -9223372036854775808 but you can't represent the +9223372036854775808 you need to negate... so you have to do... something... so that you don't overflow before you negate. There's a bunch of ways to do this. None of this belongs in the document :D You could take the position in the documents that the system behaves as though numeric literals could be negative and call it good. I wouldn't blame you... the details above make interesting trivia but poor documentation.
(4) By Larry Brasfield (larrybr) on 2021-07-20 04:06:24 in reply to 3 [link]
> 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.
(5) By Rico Mariani (rmariani) on 2021-07-20 04:57:57 in reply to 4 [link]
It's perhaps worth noting (for the discussion not the documents!) that -9223372036854775808 is of interest because it's the decimal representation of 0x8000000000000000 which is bound to come up in bitmasks etc. So it's important that it works correctly.
(6) By anonymous on 2021-07-20 05:16:20 in reply to 4 [link]
This detailed talks sound to me like a „storm in a glass of water“. I cannot see 128bit technology coming in near future. And even then the issue with binary number limitation and sign flip and negation will persist. … just my $0.02
(7) By Larry Brasfield (larrybr) on 2021-07-20 05:21:31 in reply to 5 [link]
> ... perhaps worth noting ... Perhaps. But I am distrustful of those who intend 0x8000000000000000 but write -9223372036854775808. > So it's important that it works correctly. Yes, it should work correctly. But if such a corner case works at the cost of some extra resource usage, (VDBE opcodes, prepare time, etc.), that is of little consequence. Do you have a corner case that does not work as documented or as can be expected from facts that are documented?
(8) By Rico Mariani (rmariani) on 2021-07-20 05:34:07 in reply to 7 [link]
> Do you have a corner case that does not work as documented or as can be expected from facts that are documented? No, I just noticed the inconsistency between the diagram and the text. The rest of the discussion is strictly recreational.
(9) By Rico Mariani (rmariani) on 2021-07-21 19:28:16 in reply to 4 [link]
You might want to introduce the boolean literals TRUE and FALSE in that discussion too. They are mentioned in the boolean section below. > SQLite recognizes the identifiers "TRUE" and "FALSE" as boolean literals [...]
(10) By Larry Brasfield (larrybr) on 2021-07-21 19:40:14 in reply to 9 [link]
I will try to get that in for next revision of the page. (I'm away from main workstation now, so remembering this might be a challenge.)
(11) By Rico Mariani (rmariani) on 2021-07-22 01:43:17 in reply to 10 [link]
FWIW TRUE/FALSE are already in the railroad diagram for literals. They don't need much more than passing reference in the literals section as they are discussed more fully under booleans.