On Sat, Jul 4, 2020 at 7:40 PM rjf <fate...@gmail.com> wrote: > 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). ) >
Well, I mentioned one of them: FoxyParser. It works off of an ANTLR grammar. However my understanding from Robert Jacobson is that ditching the LALR grammar and using something more flexible and expressive (his current thought is a Pratt parser, but in discussions with him a J Earley parser would probably work about as well) would extend its capabilities and make maintenance and tracking changes easier. > > I wrote (and posted) a lisp language parser for Mathematica's language, > years ago. > Yes, I have heard about it. I believe it was mentioned in the prior-discussion thread of several years back. And if you are the person who wrote A Review of Mathematica <https://people.eecs.berkeley.edu/~fateman/papers/mma.review.pdf>, I found that very interesting, well thought out, and interesting. It reminded me of why I dislike Mathematica and have been avoiding buying Mathematica. So thanks for these! (And for Macsyma and Franz Lisp). > A top-down recursive descent parser. > While recursive descent parsers are easier and straightforward to write, understand, and debug initially, it would require too much work to maintain them. As a stark example, in my Python decompiler, I have grammars <https://github.com/rocky/python-uncompyle6/tree/master/uncompyle6/parsers>for 26 versions of Python bytecode <https://github.com/rocky/python-xdis/tree/master/xdis/opcodes> which spans the range of Python from 1.0 to 3.9 (however many distinct "languages" one wants to call this). Yes, this is a bit of an extreme case, but there definitely has been language drift in Mathematica since the time you wrote that recursive-descent parser. Since I understand how to deal with the language drift problem without too much difficulty, I am tempted to support a little of that - legacy Mathematica code and examples are a reality. I certainly don't want to preclude using these. Therefore working off of a grammar (or DSL) is preferable, at least given my experience. At that time, (maybe still?) the > language did not have a context-free grammar, much less one that was > written down. > That was then, and this is now. As I said, FoxyParser has grammar. It may be in need of improvement but I imagine it is serviceable right now for more than I imagine that I need. And there are docs on the language such as this one <https://reference.wolfram.com/language/tutorial/InputSyntax.html>. Formally, a language is defined as a set of strings it recognizes, and there are numerous examples of strings in Mathematica that one can find. Given this, the lack of a standards-approved language grammar (which as you yourself I think have indicated may not be unintentional) while not ideal, is also not an obstacle for now. > I'm not sure what you are aiming to do. > Ah. I am sorry this wasn't clear. I think the lost first post was a little more explicit and I didn't want to replicate the effort to repeat everything I wrote, since I wasn't sure if the 2nd post would be lost as well. Overall I would like to reduce the tower of Babel for CAS systems. But that is a bit too broad and general so I would like to focus on a specific sub-goal. I'd like to be able to run the numerous simple examples and tutorials involving CAS for which are available for Mathematica, and be able run them and get reasonable results in sage-jupyter. "Reasonable results" doesn't mean exactly the same answer that Mathematica gives, but something that a reasonable person/mathematician would say represents a valid answer in the CAS framework that was given. If that system can't give an answer, there are several possibilities: - live with it, - change the request, - fix up the system which might involve coding a compatibility routine, or improving the transpiling system, or - switch to a different CAS backend (and possibly fixing as above ...) > 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. > Yes, I am aware of that. I am sorry that wasn't made clear initially. > > 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. > Right. By "Sage" I wasn't thinking of "sage", the back-end part called that was historically "sage", but the part that claims not to reinvent the wheel but to provide a car. Perhaps I should have written "sage-jupyter" or something like that to make this more clear. I am thinking of something that would replace or hook into sage.repl.preparse <https://doc.sagemath.org/html/en/reference/repl/sage/repl/preparse.html>. This "sage" already supports <https://www.sagemath.org/links-components.html> Maxima, Sympy and fricas as a sage package <https://wiki.sagemath.org/spkg> or (spkg). > > 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. > Yes, I have one of these as a demo program <https://github.com/rocky/python-spark/tree/master/example/expr2> for the J Earley parser I use and work on. What I am not aware of is something a little more sophisticated like sage.repl.preparse that understands the underlying semantics a little bit better. In the lost post, I closed by positing that in the far future something like this would be able to recognize which backends (of the ones installed) have features which would support the given request. And going further in the hand-wavy far future one might imagine running the request on multiple or different backends and stitching together answers. But just showing a translation from one CAS language to another would ease the Tower-of-Babel problem and is a by-product of this kind of effort. > > 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 a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/sage-devel/b7e13235-6acd-48c4-8d1f-d1c82c563e89o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANCp2gY5zbcAK3f21KP%2BbaCy7_pfdM6_n_CopMSWA1FFFnsDVw%40mail.gmail.com.
