Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

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: [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.
>
>




  • Prev by Date: Re: pattern example
  • Next by Date: Graphs in Mathematica
  • Previous by thread: Re: Again : Is there a BNF for Mathematica?
  • Next by thread: Re: Again : Is there a BNF for Mathematica?