MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

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









  • Prev by Date: Re: Defining Formatting and Notation
  • Next by Date: Re: Position
  • Previous by thread: NDSolve issues with initial and boundary conditions
  • Next by thread: Re: Again : Is there a BNF for Mathematica?