On Sun, Feb 04, 2018 at 02:27:00PM +0100, Nicolas George wrote:
Michael Stone (2018-02-04):
But a better parser would allow the same functionality, without being
confusing, inconsistent, and hard to maintain. So yes, I'll stand by
"complete misfeature".
Can you describe what you mean by "better parser" in more details?
Beware that the "same functionality" includes "same convenience".
Convenience is hard to achieve.
Well, it's not particularly convenient for people to have to constantly
wonder why the parser isn't doing what they think it should do. I've
been getting the questions and bug reports for 20 years, so trust me
when I say that people have trouble predicting the output of a given
input.
As far as "better parser" that means something that requires the input
to be fully specified, and does not try to guess based on natural
language parsing. For example, what does "last month" mean? What does it
mean when you're on the 31st and the previous month didn't have a 31st?
What date is 1/2? What time zone is "EST"? Making guesses seems
"convenient" but when you hit corner cases and things break horribly,
that's not convenient after all. Most date parsers address this by
requiring a format specifier along with the input, so you can say
something like "parse '1/2' assuming the input is
numericday/numericmonth". Is it less "convenient" to have to specify the
format? Maybe, but it's also a heck of a lot more reliable. Someone else
pointed out postgresql's date parser, which lets you do things like
specify a date and then add something like "interval '1 day'".
Specifying the fact that a particular string is an interval makes the
parsing much more regular than trying to pull the interval out of
natural language. At one point date would appear to properly parse
ISO8601 input (YYYY-mm-ddTHH:MM:SS) but it interpreted the "T" as a
timezone specifier instead of the ISO8601 delimiter. (Compare output
with YYYY-mm-ddUHH:MM:SS or YYYY-mm-ddSHH:MM:SS.) Why would it ever have
been "convenient" to put a alphabet character timezone specifier after
the date and before the time? Who knows, but the natural language parser
was doing its best to guess a meaning for the input. That particular
issue was fixed, but how you can tell whether you're using a version
that works the old way or the new way? (Answer: you can't easily do so.
If you had to specify a format it would be easier to hard fail if trying
to use a format that wasn't understood rather than soft fail and produce
random output.) Is it "convenient" that there's a natural language
parser that only understands english? Maybe, if you speak english?
Mike Stone
