> > Maybe the parser could be useful if rewritten in Julia:
Side tracking a bit, but one of the reasons I use SymPy instead of something like Maxima is that it meshes seamlessly into the language infrastructure. By writing a parser and creating another system means that it can't use julia's ecosystem without modification. I'd rather see a CAS work within Julia's parser framework. But that's just me. I am more concerned now in getting correct logical behavior than efficient > application of rules. Making it just *work* is certainly a priority, but design decisions made now can make things tricky later on. Especially with the design of your internal representation. How you represent expression trees and assumptions can seriously affect the performance of matching/traversals/replacements. On Mon, Jan 26, 2015 at 11:47 AM, Francesco Bonazzi <franz.bona...@gmail.com > wrote: > > > On Monday, January 26, 2015 at 6:11:33 PM UTC+1, lapeyre....@gmail.com > wrote: >> >> >> Another resource is Richard Fateman's mma4max >> <http://www.cs.berkeley.edu/~fateman/lisp/mma4max/>, which I see has >> updates since I last built it. It aims more or less to implement mma in >> common lisp. In fact it has a Julia-compatible license and a complete >> parser written in common lisp. IIRC the comments show that the pattern >> matcher is not perfect, but I think it is complete. >> > > Maybe the parser could be useful if rewritten in Julia: > http://www.cs.berkeley.edu/~fateman/lisp/mma4max/parser.lisp >
