On 05.02.18 10:02, Michael Stone wrote:
> IIRC it started out as a YACC function in the late 80s, and is now a Bison
> (YACC+GNU extensions) library.

In that case it has a precise grammar, expressed in BNF (Backus Naur
Form), though the lexer (I've always used lex together with
yacc/bison) could add a bit of elastic if the designer had a
free-wheeling approach. The existing flexibility then arises primarily
from explicit alternatives in grammar rules.

A BNF grammar is ideal for discussing in abstraction from the code, and
could be tweaked, both to correct erroneous results, and to add
alternative syntax which is more user-immune, if that is desired.
(But GIGO can also be cured by eliminating the GI.)

In any event, the one purportedly strange grammar example presented so
far was straightforward, both in behaviour and analysis. The one other
proposed as a challenge was nothing other than dd/mm order ambiguity.
(Purely a geographically isolated input confusion, having nothing to do
with "date".)

> There are still people who work on it--the debug option added a couple
> of years ago has made it *much* easier to understand why it does the
> things that it does. I'm not sure that if I were implementing a new
> option I'd use the bison code at all (it does probably limit the
> contributor pool).

A fork, with a new name, is on open prairie. For my money, the BNF
grammar and bison is an asset. (Even if debugging shift/reduce and
reduce/reduce conflicts can necessitate resort to old notes from previous
efforts, until one is back up to speed.)

> The bigger issues aren't the choice of implementation language,
> they're 1) getting buy-in on what the replacement should look like and
> 2) getting people to use something different. It's tough, because
> almost every linux system out there has date(1) with the existing -d
> parser, and it's easier to assume that's there than to use something
> else. (E.g., it's possible to use python or perl or other scripting
> language one-liners with any number of date libraries to add much more
> maintainable date handling to their scripts, but most people just
> stick with the date(1) they know rather than using one of the
> alternatives.)

But date(1) is fine as-is, as great now as 30 years ago - better even.
If newcomers would suggest grammar extensions (in BNF), then they could
perhaps be trialled.

Perl is the quintessential write-only language, which with a bit of luck
will die out before it catches on, and is python that monstrosity which
lacks code block delimiting, and so uses indenting in lieu?

Erik

-- 
> Am I correct that perl5-porters is the proper forum for submitting
> my ideas?
I think you didn't get a reply because you used the terms "correct" and
"proper", neither of which has much meaning in Perl culture. :-)
                                                       -Larry Wall

Reply via email to