Re: Again : Is there a BNF for Mathematica?
- To: mathgroup at smc.vnet.net
- Subject: [mg119235] Re: Again : Is there a BNF for Mathematica?
- From: David Bailey <dave at removedbailey.co.uk>
- Date: Wed, 25 May 2011 19:33:17 -0400 (EDT)
- References: <irijpq$qf8$1@smc.vnet.net>
On 25/05/2011 10: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. > Unfortunately your message has been somewhat garbled by pasting UNICODE characters into your message. I do agree with Murray, in the sense that all the interesting issues would be not really syntactic. For example, there is no end of fun to be had with MakeBoxes and MakeExpression. I am very unclear what it is that you yourself really want to do. Do you want to write a code analyser of some sort? I wrote a little debugger package (available from my website) that starts from the BoxForm's that you can see if you open a notebook with a text editor, or use NotebookGet on a notebook. This isn't a bad way to manipulate Mathematica code, because the parsing into boxes has already been done. I'd say, re-writing code to improve its performance or readability is a job for a human, not a program. There are so many issues - such as the packed array issue - that are not syntactic. David Bailey http://www.dbaileyconsultancy.co.uk