> I look forward to comments telling me how wrong I am.
Okay, I'll try to explain.
The job of a parser is to perform the opposite of stringification as precisely as possible. That string source is not always a human typing on a keyboard.
If your stringifier doesn't output scientific notation, then you reject scientific notation because it's invalid data, plain and simple. It's completely irrelevant that to a human it still looks like it could be some number. It's like picking up the wrong baby at the hospital. It might be lovely and all, but it wasn't what you were supposed to get, and that matters. It's a sign that someone screwed up, potentially badly, and your job is to hunt down where the bug was and how to address it, not just roll with whatever came your way and win some competition on how long you can ignore problems.
If you want to parse natural language then sure, it makes sense. That's what flags and different functions are good for. It doesn't mean that has to be the default. As far as programming languages go, the default assumption is that your Parse() is parsing whatever your ToString() produced on the same type.
This is the kind of thing Services on MacOS used to be for - type 1e9 into a text box, hit command option control alt meta escape shift B and it converts it to 1000000000.
> While we’re on the subject of hex numbers, I may be following this up with a proposal that “H” should mean “times 16 to the power of” in a similar style, but that’ll be for another day.
I like this idea but I think it should be "HE" for hexadecimal exponent.
I’m not sure why this is a “proposal” for other string to int parsers rather than a function the author wrote themselves. It seems rather trivial to implement on top of something like strtol (or whatever your language’s equivalent is).
7 comments
[ 2.7 ms ] story [ 35.4 ms ] threadOkay, I'll try to explain.
The job of a parser is to perform the opposite of stringification as precisely as possible. That string source is not always a human typing on a keyboard.
If your stringifier doesn't output scientific notation, then you reject scientific notation because it's invalid data, plain and simple. It's completely irrelevant that to a human it still looks like it could be some number. It's like picking up the wrong baby at the hospital. It might be lovely and all, but it wasn't what you were supposed to get, and that matters. It's a sign that someone screwed up, potentially badly, and your job is to hunt down where the bug was and how to address it, not just roll with whatever came your way and win some competition on how long you can ignore problems.
If you want to parse natural language then sure, it makes sense. That's what flags and different functions are good for. It doesn't mean that has to be the default. As far as programming languages go, the default assumption is that your Parse() is parsing whatever your ToString() produced on the same type.
I like this idea but I think it should be "HE" for hexadecimal exponent.