Am 10.03.2014 20:10, schrieb Aditya Shah:
@Jo Okay let us assume that modgrammar allows us to share grammar.
Okay.
Yeah. That's the implicit assumption I've been making; sorry for not
making that clear.
If it doesn't, the game changes.
> In that
case I have no problem to remove the EBNF dependency, although I would say
that it is a good thing to have around.
Well, let's agree to disagree on that one - I definitely see a price here.
Maybe it's because I have done more maintenance work in my life. Given
that SymPy, like many Open-Source projects, has limited manpower, I tend
to weigh maintenance overhead very highly; we don't want to get bogged
down work on mechanism, even if the mechanism is small - all those small
mechanisms add up and in the end the whole system is still clearly
structured but too large to make any significant progress given the
available manpower.
Actually I see all those foreign-syntax import things as a detraction
from SymPy's core mission already: It's not making the expression
transformation code faster or more powerful, it's not improving on error
messages, it's not making the transformations more predictable or
consisetent.
Not that I'm saying this shouldn't be done - it allows people to easily
migrate towards SymPy, so it's important to build the user base. Still,
it's a detraction. PR if you will. That kind of stuff is important, but
it should require as little overhead as possible.
> Plus i haven't had the time to read
the entire documentation of modgrammar (too much coursework!).
Heh. I haven't either, I have to admit.
It's probably a good idea to postpone further discussion until at least
one of us has a better grasp of what modgrammar can and cannot do.
> I intend to
do that in community bonding period. So till then let us keep the
architecture this way or else i'll modify. Seems fair?
/shrug I'm just offering advice on a take-it-or-leave-it basis (I'm not
mentoring due to lack of time), so you're free to do as you wish anyway.
My suggestion would be to start with getting a proof-of-concept done
with modgrammar (no EBNF), and see how well that works.
If modgrammar turns out to be useless, I'd suggest trying Spark.
If that doesn't work either, then we probably really need to generate
modgrammar or Spark code.
However, code generation, while attractive in theory, comes with many
strings attached in practice. It complicates the build process, and the
generated code tends to trigger code paths that manually-written code
does not, and that means you are more likely to hit that one absurd
showstopper bug than those who simply code in Python. Also, code
generation is harder to debug because you need to debug at two levels at
the same time: Code generator and generated code. It's more likely that
you'll have bugs that way.
--
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 [email protected].
To post to this group, send email to [email protected].
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/531E1349.8090303%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
