Again : Is there a BNF for Mathematica?
- To: mathgroup at smc.vnet.net
- Subject: [mg119212] Again : Is there a BNF for Mathematica?
- From: "E. Martin-Serrano" <eMartinSerrano at telefonica.net>
- Date: Wed, 25 May 2011 05:56:23 -0400 (EDT)
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. Regards E. Martin-Serrano