Handle number exponents with signs in filter

[baodrate]

1e-1 and 1e+1 in filters are now parsed correctly.

closes #79

[baodrate]

first time working with chumsky (or rust, really), so apologies if it correctly appears like I don't know what I"m doing.

I also noticed that:

• jq allows .5 in both filters and JSON even though it's not a valid number according to JSON spec
  • Actually found this in some .jq files I had. But I prefer jaq's stricter JSON parsing so not sure it's worth it to implement this for only filter parsing and breaking consistency between the two syntaxes
• jaq preserves 2e3 literally when it's in the input JSON (jq produces 2000), but when 2e3 in the filter produces 2000.0

[01mf02]

That's looking good --- congratulations for having figured this out without previous Rust and chumsky experience!

• jaq preserves 2e3 literally when it's in the input JSON (jq produces 2000), but when 2e3 in the filter produces 2000.0

This is on purpose. jaq tries to keep JSON input faithfully, because its contents might be unknown to the user, whereas jaq optimises the filter, because it is supposed to be known to the user. If we would not do this, then a simple filter like . + 1.0 would convert 1.0 from a string representation to a floating-point representation for every single input value, which would have a massive impact on performance.

[baodrate]

That's looking good --- congratulations for having figured this out without previous Rust and chumsky experience!

😄

jaq tries to keep JSON input faithfully, because its contents might be unknown to the user, whereas jaq optimises the filter, because it is supposed to be known to the user

That's reasonable. I was more-so pointing out that 2e3 gets transformed into 2000.0 where I would assume an int (2e3 -> 2*10^3 -> 2*1000 -> 2000). not a big deal though because you probably want a float if you're working with scientific notation (see relevant discussion), and actually handling this would complicate the parsing beyond the current isize.from_str()