On 2 September 2010 23:41, rjf <fate...@gmail.com> wrote: >> There's no README file in the source code I found of yours, so it's far from >> obvious to me how I would use it. > um, I don't know where you looked, but > > here is one place.. > http://www.cs.berkeley.edu/~fateman/mma1.6/
Adding a README file would help a lot > I forget exactly, but I think it is approximately, get all those > files in that directory. start a lisp in that directory. > > (load "capsonlyparser.lisp") > (in-package :mma) > > (p) Thank you - I will give it a try. > then type some mathematica and hit two returns. > > Better lisps that don't do everything in caps would use the regular > parser file, which is easier to read and modify. Hopefully ECL would be able to use the simpler file. >> Certainly from reading the paper, it gives no indication that this runs as >> part >> of Maxima. > > Right. The adaptation was the work of someone else to load it into > Maxima. Check sourceforge. > John Lapeyre was the author. Thank you. > It gives the impression to me that this is written in lisp, to run >> under the lisp interpreter directly - not under Maxima. I'm a bit confused on >> this issue. > > My program can run without Maxima. > >> >> > The intent in that project is mainly to take mma syntax for >> > expressions and map it into >> > maxima, and not take the big step of having a more-or-less full >> > mathematica >> > evaluator in Maxima. >> >> How complex in your opinion would it be to create a parser for Mathematica in >> C/C++/Python/Lisp/whaterver-is-most-suitable which could call the right part >> of >> Sage for a particular tasks? In other words, call Maxima for integration, >> perhaps the GSL for Bessel functions, etc. > > Well, if you want to load GSL or whatever into lisp, then you can use > the parser that > is already in Lisp. Can you elaborate more on this - I do not know what you mean. > As for a "whatever is most suitable" to create a parser for > Mathematica, that would have > to be Mathematica, since it is already done. If you want an #2, I > would say Lisp. >> I'm pretty sure this is a non-trivial project, but my background is >> engineering, >> not maths or computer science, so I don't have a lot of understanding of the >> complexity involved. >> >> I just bought a book on Lex + Yacc (around the US equivalent of $1 used). >> I've >> no idea if they would be suitable tools or not, but at 1$ I'm not going to go >> bankrupt. > > Unfortunately, WRI does not give you a context free grammar for > Mathematica, nor > does it give you a description of the tokens that you can use. So Lex > and Yacc are > not directly applicable. How far could one get with Lex/Yacc? Some of the constructs I see in your paper, such as the confusion that can arrise with ! for note and !! for double factorial, are a little odd. One could easily re-write small parts of code that are ambiguous. If one was able to write something able to parse 99% of Mathematica code, that would probably be enough for me. Even if the parser was 100% perfect, one would only be able to implement a small subset of Mathematica's features in Sage using the current Sage code base. >> I gather there are several types of parser LL, LR etc. I've no idea what >> type is >> best for parsing Mathematica. > > Since Mathematica's language is not a context free language, as far as > I can tell, > none of these abstract classes of parsers will entirely work. There > are constructs in > Mathematica that appear to require ad hoc parsing techniques. Though > much of it > can be done by some kind of table-driven parser, e.g. LALR or LL. The > MockMMA > lexer and parser are modified from a recursive descent parser with > variable look-ahead. This is making me think perhaps Lex/Yacc approach may not be so entirely dumb. > My suggestion is that you find someone who knows lisp, or is willing > to learn it, and > then use the parser, free. > or I suppose you could have someone write a parser in Python, but then > you'd might > have to write a substantial portion of Lisp, too, for the > representation and manipulation > of the intermediate expressions. So Lisp turns out to be a pretty > substantial win. > > > > RJF I'm quite happy to be that someone who learns Lisp - I'm serious thinking of buying a book on it. Unfortunately, they tend to be quite expensive, as do books on writing compilers. However, one very practical problem is that if one writes code in Lisp, the number of people that would be willing to extend that code drops dramatically, as the number of people knowing the language drops. I'm not one who preaches Python is God. There have been many languages come and go. I don't know what the lifetime of Python will be, but I suspect it will be found only is history books when C is still a common language. I know you don't happen to like C either. I'm not denying Lisp my be technically the easiest language to do this in, but that is not the only factor to be considered if code is going to be edited by a number of people. Of course, lex/yacc falls into the same problem as Lisp - they are not well known. At least Python and C are, though the problem may be a lot harder there. Dave Dave -- 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
