On Feb 25, 6:55 am, David Kirkby <david.kir...@onetel.net> wrote: > On 25 February 2011 10:48, Ira Baxter <idbax...@semdesigns.com> wrote: > > > On Feb 25, 3:05 am, David Kirkby <david.kir...@onetel.net> wrote: > >> On 25 February 2011 05:57, Ira Baxter <idbax...@semdesigns.com> wrote: > > >> > Mathematica is otherwise not hard to parse, and you don't need > >> > a hand-written parser to do it. > > > Part of this discussion started because Dave suggested that > > writing and maintaining a hand-written parser was harder > > than a parser-generator one, > > That's the impression I've got from spending a bit of time on reading > compiler books. I personally don't have a computer science background, > so have very little knowledge of this area, whereas clearly this is > one of your areas of expertise.
Your impression is right. Many langauges can be parsed with top-down parsers (in fact, with enough hacking, you can probably do them all). But many are hard and that's the point of a parser generator. Your orginal point, and the one we follow, is that you have a big nasty parser generator, you should use it for everything including the easy stuff. > Wolfram is a bright guy, so I concluded (perhaps incorrectly), he > would have done it the easiest way possible. 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. Easy is relative. Using a parser generator isn't as easy if you are coding in Fortran (probabaly not terribly hard, either, but if you've coding everything in Fortran, that thought may not cross your mind). And if you happen to have a top-down easy-to-parse langauge, you don't need to. I suspect (but I haven't asked Wolfram) this is what happened. It makes perfect sense to me. > Richard Fateman has written a parser for Mathematica in Lisp No surprise, and no surprise it is hand-written. LISPers do a lot of that. > 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 thing you are asking the wrong question. Building the parser, however done, is such a small part of the overall work that goes into a system that it really doesn't matter how you do it. Nor would it be easier or harder in interesting ways in any language you choose; you can code a parser by hand in all these lanuages, and if you look, you can find parser generators for all of them. The easiest thing to do is write it using a parser generator. Richard has made some noise about MMa not being LALR(1) which would kill most conventional parser generators, but I'm not sure I agree with that analysis. Our GLR parser generator happens to analyze its grammar as to whether it is LALR or not; for the particular grammar I have, it says it isn't LALR-like in a few places. This is pretty typical of a simple grammar when a parser engineer first crashes his grammar against an LALR parser generator like YACC. There's fiddly stuff and black magic you can do to a grammar that usually fixes that kind of stuff, and there's always resorting to hacking (Richards "lexer asks the parser for help" is one of them). People succeed with standard parser generators by spending energy doing this, and this is why parser generators are widely accepted: you can get them to work. Based on our parser analyzer output, I suspect an LALR version wouldn't be difficult. We didn't bother with an LALR version, because we have the GLR version, and I have no hacks in the parser which made this grammar singularly easy to build. Because its an easy grammar, you could quite reasonably do the top down version. For instance, you could simple steal, uh, reuse Richards code as a direct design if he coded it cleanly. The always hard part is, what grammar will you use? Wolffram doesn't publish one. I invented ours based on my long experience and lots of staring at the MMa reference manuals. If you are an expert at building parsers, and understood MMa really well, my guess is you could build a MMa parser (either way) in a few weeks. Probabaly what Richard took. > 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. That's a matter of personal taste. If you want a hobby, this is a fine proposal. Our customer base is composed of people that want to get on with the larger task; the JPL guys took our MMa parser because it meant they could concentrate on a oode analysis/code generation/some MMa generation task immediately. And that's what DMS with the predefined base of langauge parsers for lots of (hard-to-parse) langauges, and all the other built-in machinery give them the ability to do. > Dave Ira Baxter, CTO Semantic Designs -- 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
