Am 10.03.2014 09:33, schrieb Aditya Shah:
@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.
Not sure that that will really be the case. Usually, using one tool
(one's own or that of somebody else) makes you dependent on that tool,
simply because you set up things the way that that tool needs, simply
because you don't know (yet) what the other tool will need.
So... I do not think you'll reap the benefits you assume.
(Premature factoring-out, the twin of premature optimization, if you will.)
> Even if the underlying framework is
changed, that detail has been abstracted and so user needn't worry about
that.
I do not think that a standard SymPy user will ever try to build another
XYZ-to-SymPy converter.
IOW you have a solution, but is it solving a problem?
> 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,
Oh yes it does.
Not user productivity, but maintainer productivity. Both the maintainers
of the grammar files (who now need to know your specific EBNF dialect in
addition to modgrammar), and the maintainers of the import subsystems.
That effort would be justified if it added valuable functionality, but I
don't see that.
> 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.
Those users will simply feed their Mathematica code to SymPy and
complain if it doesn't work.
They're primarily interested in getting results, not in dealing with
input languages.
Your approach does have merits for those who, like you, come from an NLP
background and want to work at the EBNF level.
Everybody else either has no advantage (end users), or doesn't care
(maintainers who want to update the syntax files - they'd have to learn
either the EBNF dialect or the modgrammar API, that's essentially the
same), or have a disadvantage (import subsystem maintainers).
--
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/531D9997.1000608%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
