On Feb 25, 4:55 am, David Kirkby <david.kir...@onetel.net> wrote: > > > Wolfram is a bright guy, so I concluded (perhaps incorrectly), he > would have done it the easiest way possible.
That would be to ask someone else to do it. > I got the impression that > would have been to use pre-written tools for the lexical analysis and > parsing, rather than hand craft them, which I understood had high > maintenance costs. > > > Writing a top-down recursive descent parser isn't terribly hard for > > a lot of languages; I've done many this way. > > Mathematica in fact is probably singularly > > easy, because of its Lisp-like syntax. Lisp parsers have been > > pretty much hand-rolled from day one because of this > > rather simply notation with convenient brackets to > > guide the parser as to when to push, and when to pop. > > Richard Fateman has written a parser for Mathematica in Lisp > > http://www.eecs.berkeley.edu/~fateman/papers/lmath.ps > > I was interested if his comments in the section "Lexical Analysis and > Parsing" and as to how accurate they are. > > His code is public > > http://www.cs.berkeley.edu/~fateman/mma1.6/ There is a better version now. http://www.cs.berkeley.edu/~fateman/lisp/mma4max (see the file parser.lisp in particular) This directory has programs that should work in almost any common lisp, even Gnu Common Lisp, which has the distinct DISadvantage of clumsy handling of upper and lower case characters. > > I personally find Richard can be helpful, but some of his comments > (like those directed at you and your company) are somewhat less than > helpful. > > He wrote a review of Mathematica some time ago. > > http://www.math.bme.hu/~jtoth/FelsMma/mma.review.pdf you can find a copy without going to Hungary :) > > > The rumors that I heard was the the early versions of MMa > > were based in Fortran. My guess is that Wolfram did write > > a recursive descent parser by hand, because you can do that > > easily even in Fortran. Oddly enough, Fortran does not directly support recursion, so one would have to simulate it in some clumsy fashion to write a recursive descent parser. > > Would you mind answering the following question, and I would not blame > you if you chose not to! > > If someone wanted to write an open-source, cross-platform parser for > Mathematica, without using commercial tools like that produced by your > company, what approach (or approaches) would you consider sensible > ones? Would this be easier in Lisp than in say C or Python? I gather you are asking the question of Ira, but the answer is pretty clear that it would be easier in Lisp because it could simply be copied from an existing program. Since Lisp has a programmable read-table, much of the lexical analysis can be done easily without reference to any external libraries etc. It is not, as they say, rocket science, to write a parser. Undergraduate computer science students routinely write parsers for homework. > > > I would further guess there isn't/wasn't any great reason to change > > it. > > That makes sense, If Wolfram had a Mathematica parser in FORTRAN, there would certainly be reasons to deep-six it. Interoperability, error handling, a more complicated build-sequence -- come to mind. > > > Final remark: the effort to write the parser is tiny compared to > > the effort to build the rest of any interesting system attached > > to a parser. The same is true for maintenance costs. > > Yes, that's clear. But Sage does have a reasonable subset (and in some > cases superset) of Mathematica, so hooking up a Mathematica parser to > Sage (which is basically Python-like), could have some uses and would > not involve writing all of Mathematica. > Sure, if someone has the bizarre preference for Sin[x] instead of sin(x). But it is a mischaracterization of Mathematica to think that it is kind of like Sage but with a different syntactic front end. Mathematica users think that f[x_]:=x+1 defines a function f. It sorta works to think that. For a while. But it is false. That command means "define a pattern so that f[x] is replaced by x+1 everywhere. Consider, for comparison, these two definitions ... Int[u_Plus,x_Symbol] := Map[Function[Int[#,x]] ,u] Int[a_*u_,x_symbol]:=a*Int[u,x]/; FreeQ[a,x] There are patterns in the "binding" of formal parameters to actual arguments. The first definition changes Int[a+b+c,z] to Int[a,z]+Int[b,z] +Int[c,z] The second definition changes Int[a*b*Sin[z]*Cos[z],z] to a*b*Int[Sin[z]*Cos[z],z] It may be that Sage has a pattern-matching substrate that is happy to do this. (If it doesn't I can supply one, of course it is in Lisp). But my expectation is that the command-line etc structure of Sage is more like a sequence of python-like commands, calling functions upon functions. Maxima has that kind of command functionality, for the most part, although tellsimp changes, via patterns, the simplifier, and so resembles in some respects a pattern transformation system. (If Sage DOES have patterns, that would make it far more plausible to map Mathematica into Sage, but only if the pattern system is essentially a clone of Mathematica.) > However, the approach of an open-source multi-platform clone of > Mathematica, no using Sage (but some components of it, such an MPIR, > MPFR etc), would be an interesting open-source project. Uh, thanks for the endorsement of Mockmma. > > > Ira Baxter, CTO > > Semantic Designs > > Anyway, thank you Ira. You have convinced me that Richards numbers 1 & > 3 were wrong. Again, readers of this exchange will have to make their own judgment. 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
