@Jo thanks for chiming in. I understand your sentiment but from your reply, I gather that you have properly understood my proposal. Firstly, adding EBNF adds 1 extra layer which can anyways be overridden by an experienced programmer such has yourself. Secondly, I propose to keep the extra layer to maintain the API in case we grow discontent with modgrammar. In my scheme of things, you write the grammar in EBNF form, then the Spec to Grammar converter generates a Python file (which BTW anyone can write themselves if they know the format that nodgrammar takes the input in) which serves as an input to modgrammar. Should we decide to replace modgrammar with say Spark, we can change to code of Spec to Grammar converter file to generate the corresponding input to Spark. Here, adding one extra layer offers a big advantage. Even if the underlying framework is changed, that detail has been abstracted and so user needn't worry about that. And yes, if the user knows the format of the Python file which serves as an input to either of the framework, he/she can bypass the first stage and directly write the input file (generally in Python). Adding an extra layer doesn't hamper the productivity in any case, rather it enhances the same in the case that user doesn't know or doesn't want to bother with the details of how input file to the PGF is generated.
I hope these arguments satiate your questions. Regards, Aditya Shah -- 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/bef15799-db98-417e-9225-06ea2c2096fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
