Re: Again : Is there a BNF for Mathematica?
- To: mathgroup at smc.vnet.net
- Subject: [mg119792] Re: Again : Is there a BNF for Mathematica?
- From: Szabolcs Horvát <szhorvat at gmail.com>
- Date: Wed, 22 Jun 2011 07:29:17 -0400 (EDT)
- References: <irijpq$qf8$1@smc.vnet.net>
If you are looking to implement a Mathematica parser yourself, you might want to look at some earlier efforts first: http://omath.org/w/index.php?title=Main_Page#Developers http://stackoverflow.com/questions/1608380/parser-for-the-mathematica-syntax http://www.mathics.org/ These pages contain links to several other projects (most dead by now). On 2011.05.25. 11:57, E. Martin-Serrano wrote: > On 2009 Murray Eisenberg posted the article linked below > > > > http://forums.wolfram.com/mathgroup/archive/2009/Apr/msg00232.html > > > > In which he wrote: > > > >>> It's not at all clear to me that a BNF would be of any great > use for Mathematica : after all, "everything is an expression" and so if > you avoid any of the "special input forms" such as =, :=, /@, {}, = > [[]],>>etc., along with prefix, infix, and postfix special forms, then > the grammar is utterly simple. > > > >>> The complexities arise from (1) Attributes, such as Hold, which do not > explicitly appear as part of the syntax one uses in entering expressions > but affect the evaluation; and (2) the special input>>forms, where you > have to begin worrying about order of precedence. > > > > My point now is: > > > > Would the Murray's remark be still valid if we talk about a > BNF grammar whose purpose is to write a parser to make available just > the expressions of the form ( symbol := expression =E2=94=82 symbol > = expression ) after discarding all the stuff on attributes and > evaluation order? I am still concerned, as I posted a year ago o so, > with the =E2=80=98data dependency graph=E2=80=99 or =E2=80=98what we > could call =E2=80=98data dependency part of the parsing tree=E2=80=99. > > > > The underlying idea is to extract all the assignments (left and right > sides) in the code preventing the evaluation of the right hand sides. > Wrapping the right hand sides in assignments with > =E2=80=98hold=E2=80=99 is unacceptable for my purpose and need. > > > > Counting on a BNF (affix) Grammar, a simple way to extract the data > dependency tree/graph would go like this: > > > > 1) Save in plain text format the piece of code (in a notebook) that > one needs to parse (all hidden code corresponding to the notebook > interface would be dropped). > > > > 2) Perform a first parsing step to drop all the elements mentioned > or referenced by Murray (Hold and controls of order evaluation), leaving > only the code corresponding to assignments and function definitions. > > > > 3) Perform a second parsing step on the plain text obtained in the > previous step, which will produce a set of assignments regardless they > are delayed assignments or not. > > > > Maybe my ideas were clearer if I compare the above procedure with > another, perhaps equivalent (?), method; consisting in performing a > separate (or concurrent) recursive descendent parsing on all > {DownValues, UpValues, OwnValues} for the symbols in the piece of code > we are interested in. In which case, the parsing trees got in each > separate step {DownValues, UpValues, OwnValues} will defined some valid > form of data dependency graph for the whole piece of code. > > > > Then, with, say, Combinatorica, we would be able to explore and find > important properties of the parsed code, easing up the task of: 1) > Speeding up complex and tricky dynamic programs, 2) rewriting programs > written in older (sometimes very old) Mathematica versions, and, 3) no > less important, writing the final version of experimental programs > written incrementally, with step by step incremented functionality, > which typically result in something nearly unreadable. > >
- Follow-Ups:
- Re: Again : Is there a BNF for Mathematica?
- From: "E. Martin-Serrano" <eMartinSerrano@telefonica.net>
- Re: Again : Is there a BNF for Mathematica?