Re: Again : Is there a BNF for Mathematica?

*To*: mathgroup at smc.vnet.net*Subject*: [mg119814] Re: Again : Is there a BNF for Mathematica?*From*: "E. Martin-Serrano" <eMartinSerrano at telefonica.net>*Date*: Fri, 24 Jun 2011 07:44:00 -0400 (EDT)*References*: <irijpq$qf8$1@smc.vnet.net> <201106221129.HAA09145@smc.vnet.net>

Thank you very much -----Mensaje original----- De: Szabolcs Horv=E1t [mailto:szhorvat at gmail.com] Enviado el: mi=E9rcoles, 22 de junio de 2011 13:29 Para: mathgroup at smc.vnet.net Asunto: Re: Again : Is there a BNF for Mathematica? 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. > >

**References**:**Re: Again : Is there a BNF for Mathematica?***From:*Szabolcs Horvát <szhorvat@gmail.com>