Am 10.03.2014 12:41, schrieb Aditya Shah:
@Jo thanks for the swift reply. I'll try to explain my position to you.
Since, I come from a bit theoretical background, I do prefer to use EBNF to
manipulate grammars. As you said, that is a selected group of people and I
believe that. Also, on the suggestion of @asmeurer, if you read 6th last
post, you'd find that people wanting to work with Python can do so directly
without bothering with explicit notation.
Sure, but adding another layer on top of that just because you can (and
want to) doesn't necessarily improve things. Actually the price is a
higher rate of bugs (more code means more bugs), and a more complicated
system.
> Here I ask you one thing. I have
seen the documentation of modgrammar and even Spark and while both of them
use Python for directly represent the grammar, you'd find that without
prior knowledge of EBNF, you cannot write the python code. It is because,
they encapsulate the EBNF form by Python code and so I believe that EBNF
should be known a priori.
Well... structurally it's always the same, but at that level, preferred
syntax doesn't matter.
> Plus, as you said no user is ever going to bother
about XYZ-Sympy converters. That would rest on developers who set out to
define those parsers.
Exactly.
> I do think that people who intend to create parsers,
would have prior knowledge of EBNF. Even if they don't as you claim, they
can always bypass that step entirely.
Those who maintain an existing parser can't, they'll have to work with
what's there.
Maintenance takes far more time overall than initial creation, so that's
a real concern.
> As for the maintenance part, if
modgrammar or any other PGF decides to discontinue or change their API, we
would have to only change the Spec to Language converter file or as you
claim learn the new API.
You depend on modgrammar anyway.
Besides, incompatible API changes are the exception, not the rule.
Plus, we're not necessarily forced to upgrade to an incompatible version
of modgrammar.
> What I don't seem to understand is that, there are
2 approaches to do the given thing and even if one is not widely popular (
as you claim), if we do add support for that, it would only serve to
empower someone who fits in that particular case to use it. So where's the
issue?
As I said: Maintenance overhead.
More code means more maintenance overhead.
And that's a really big issue, because (as I said) over time,
maintenance is more work than initial implementation.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/531DF6BC.2010206%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
