MathGroup Archive 2011

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

Search the Archive

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


  • Prev by Date: Re: Series[log[x], {x, 0, 3}]
  • Next by Date: Re: How to draw a function along y-axis
  • Previous by thread: Again : Is there a BNF for Mathematica?
  • Next by thread: NDSolve issues with initial and boundary conditions (corrected characters)