On Feb 25, 1:36 pm, Ira Baxter <idbax...@semdesigns.com> wrote:
> > It is clear that Fateman with no evidence insulted our ability to > parse Mathematica, > as well as our character. It should be clear that we can parse it > just fine. > You can decide about our character. > > Mr. Fateman does not apparantly understand what we do with our > tools, or how they work. You claim that you can parse Mathematica. You claim that it should be clear that you can parse Mathematica. You provide no evidence that you can parse Mathematica except a (rather obscure) trace of a a parse of an 8 character string. It is not clear even that the parse is correct. By comparison, the result I provided, (Part r (s)) explicitly represents the fact that the parse results in a Part[] subexpression. The output from the semanticdesigns parser does not seem to anywhere mention "Part". I don't see a resulting form in any readable format corresponding to the expression. So if you can parse the given expression, you have not shown that to me at all. Given the way this conversation started, > and the way he is continuing, > I see no good reason why I should explain any of this to him. The other evidence that you provide is that your program produces an output consisting of the number of nodes in a tree from (allegedly) parsing a Mathematica file. Is the program parsed the same way as done by Mathematica? Now none of this is THAT hard; after all WRI has been doing this for quite a few years. So has MockMMA, though the internal languages now differ by choice. For example, I parse x<y as Comparison[x,Less,y] which generalizes x<y<=z to Comparison[x,Less,y,LessEqual,z]. Instead of Inequality, I use Comparison, so I can also reasonably say Comparison[x,Equal,y]. Now I can understand that a Mathematica parser is not a big seller because, as you point out, a parser per se is not particularly useful (or THAT hard), because a very substantial effort towards providing more of the system, you can't do much with it. So commercially, it doesn't make sense to put a lot of effort into a parser. Fair enough. I asked why JPL would be interested in such a thing, but you didn't respond. Now do you actually have a Mathematica language parser or not? You might. I suggested that perhaps you didn't REALLY have a parser; it is apparently not a supported product. But maybe you do have a parser. In order to parse Mathematica programs you would need to have a representation for arbitrary precision integers and floating-point numbers. Probably omitted. Does your intermediate form of nodes allow for such things? Does your GLR parser overcome such issues? It is possible by using such tricks as encoding a 200-digit integer using 200 nodes of 1-digit each. To what extent is the GLR parser taking time O(n^3) for programs of length n? Or worse? A conventional parser, in my view, is an O(n) time/space parser. Typically LALR(1), but not necessarily. Most programming language constructs are easily parsed. Adopting a grammar and strategy that is of higher complexity is unconventional, but of course still possible. Writing a parser using GLR that also happens to be O(n) is possible with the right grammar. Devising a correct grammar for Mathematica is itself tricky; getting one that is correct and has an O(n) complexity eluded me when I first decided to write a parser; the alternative was the parser I actually wrote, and you can view. Now as for whether I understand how your tools work or not, there is not a bad top-level description of GLR in wikipedia, and a google search gets you lots of other stuff. This is not difficult technology. Should you (Ira) bother to respond? I don't care. RJF -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
