There are at least two rather complete parsers for the "Wolfram Language" which render stuff like foo[x_]:= Sin[x]+Log[x] into trees / intermediate forms/ Lisp s-expressions. (compare to Wolfram's "FullForm" which is essentially lisp with [] instead of (), and moving parens... x+y becomes Plus[x,y] or in lisp, (Plus x y). )
I wrote (and posted) a lisp language parser for Mathematica's language, years ago. A top-down recursive descent parser. At that time, (maybe still?) the language did not have a context-free grammar, much less one that was written down. I'm not sure what you are aiming to do. But to make any non-trivial use of Mathematica language ( i.e. other than algebraic expressions like a*b+c) you need to have semantics for pattern matching, language features , conditionals, iteration, numerics (bizarre bigfloat), and routines like Integrate[], Solve[] etc. You cannot map these 1:1 to anything currently in Sage, though I suppose Sage could gobble up a version of Mathics. or you could look at the lisp/Maxima code. I think openmath has lost out to mathml, but they are both, IMO really terribly unreadable, and for no good reason. There is at least one front end for Maxima that (I think) uses MathML. As long as no human has to read it, it might be OK except for being about 25X more verbose than needed. If all you care about is algebraic expressions with standard operators, + * / - ^ then the task is a simple homework assignment for an undergrad course in programming languages/ compiling. RJF On Saturday, July 4, 2020 at 12:29:27 PM UTC-7, Nils Bruin wrote: > > On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote: >> >> >> So one goal as briefly mentioned was to be able to write/use a common >> language for expressing CAS. >> > > This goal (or perhaps a little more broadly, a common language for > expressing mathematical objects) has been around for a long time and has > proven rather difficult. You should probably look into efforts that went > into OpenMath (https://www.openmath.org/) and evaluate what works and > does not work there. > > One of the early design goals of Sage was actually exactly to be a > compatibility/translation layer between different CA systems and libraries. > That's where the "expect" interfaces come from and several of those > interfaces (libmaxima, libgap) since then were better integrated to allow > translation of information on a binary level rather than just via character > streams. > > The overarching language was not particularly modelled on Mathematica, but > rather on Magma, which matches Python fairly well. > > I'd expect that you'll run into the same kind of issues that Sage has run > into if you try to replicate its efforts on a Mathematica-modelled > platform. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b7e13235-6acd-48c4-8d1f-d1c82c563e89o%40googlegroups.com.
