Sat, 27 Nov 2010 11:11:11 -0800 (PST)

Related articles |
---|

Choosing a parser for Mathematica input drkirkby@gmail.com (David Kirkby) (2010-11-07) |

Re: Choosing a parser for Mathematica input jthorn@astro.indiana-zebra.edu (Jonathan Thornburg \[remove -animal to reply\]) (2010-11-09) |

Re: Choosing a parser for Mathematica input haberg-news@telia.com (Hans Aberg) (2010-11-09) |

Re: Choosing a parser for Mathematica input drkirkby@gmail.com (David Kirkby) (2010-11-09) |

Re: Choosing a parser for Mathematica input winkzhang@gmail.com (Wink Zhang) (2010-11-13) |

Re: Choosing a parser for Mathematica input idbaxter@semdesigns.com (Ira Baxter) (2010-11-26) |

Re: Choosing a parser for Mathematica input drkirkby@gmail.com (David Kirkby) (2010-11-26) |

Re: Choosing a parser for Mathematica input drkirkby@gmail.com (David Kirkby) (2010-11-27) |

From: | David Kirkby <drkirkby@gmail.com> |

Newsgroups: | comp.compilers |

Date: | Sat, 27 Nov 2010 11:11:11 -0800 (PST) |

Organization: | Compilers Central |

References: | 10-11-017 10-11-037 |

Keywords: | parse |

Posted-Date: | 28 Nov 2010 22:20:16 EST |

On Nov 26, 5:54 pm, "Ira Baxter" <idbax...@semdesigns.com> wrote:

*> "David Kirkby" <drkir...@gmail.com> wrote in message*

*> > I'd like to write a program that uses a Mathematica-like syntax. Not a*

*> > 100% clone, but as close to Mathematica input as reasonably practical.*

*> > Can anyone suggest a suitable front end parser? I was thinking of*

*> > using LLVM for the back end.*

*>*

*> Others have noted that LLVM is much more than a parser.*

As I noted, I had not looked at LLVM much, but I was not aware it

could be used for parsing the code. I was under the impression that

for example to make a C compiler, it uses the gcc front end, rather

than parse the C code directly.

LLVM seemed to be an ideal tool for the back end though.

*> Are you trying to generate *code* from MMa syntax? Are you trying*

*> to generate code from pure MMa equations or from actual MMa*

*> programs?*

I don't fully understand the question, which is no doubt due to my

lack of knowledge.

I'm thinking of basically making an MMA clone, which accepts

Mathematica input and acts as an interpreter. However, unlike Octave,

which is a MATLAB clone, I was not looking to make a 100% clone. If

part of the Mathematica language was particularly difficult to parse,

then it would be ignored.

If for example, it was found to be very difficult to parse input like

In[1]:= Pi //N

Out[1]= 3.14159

then I would be happy to accept that this could easily be written as:

In[2]:= N[Pi]

Out[2]= 3.14159

and not worry too much about it. I'm sure the above will not be an

issue, but there are some other complex parts of Mathematica which I

thought might be very challenging.

Likewise, if there are serious flaws in the way the language works, it

might be better to not worry about being compatible, but do it better.

Richard Fateman's paper points out what he considers a huge number of

flaws, but I take a lot of what he says with a pinch of salt. He is

clearly no fool, but is very negative about almost anything unless it

is Lisp. For example, he thinks use of a space for multiplication is a

bad idea, yet that's how most people write maths. We write

2 Pi x

rather than

2*Pi*x

*> > Here's a description of the syntax*

*>*

*> >http://reference.wolfram.com/mathematica/guide/Syntax.html*

*> >http://reference.wolfram.com/mathematica/tutorial/TheSyntaxOfTheMathe...*

*> MMa (equations or programs) isn't a particularly complex language,*

*> either conceptually or from the point of view of a parser.*

*> Mostly it is Lisp S-expressions using xyz[...] instead of (xyz ...).*

It always stuck me as complex language to use, with such obscure

syntax in places, that I thought it would be very difficult to parse.

Some Mathematica code is similar in obscurity to entries for the

obfuscated C contest!

In the paper "A Lisp-Language Mathematica-to-Lisp translator" by Prof.

Fateman

http://citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.51.4310%26rep%3D

rep1%26type%3Dpdf&usg=AFQjCNG_OKvzYioUhV95ZSjVkwvLGW9xBw

he says in the section "Lexical Analysis and Parsing"

"After trying (with only modest success) various mostly-automatic

parsing techniques, we ended up with a basically hand-coded parser.

Mathematica unlike some computer algebra systems does not feature an

extensible syntax: this suggested the implementation was somewhat ad-

hoc."

I'm not sure how objective Richard's comments are though. I don't know

if

* He just wanted to have a dig at Wolfram Research.

* Richard is right, and most automatic parsing techniques are not

appropriate.

* He chose inappropriate mostly--automatic parsing techniques. (He

does not list what he tried)

* He chose the right parsing tools, but did a poor implementation

Much of the paper suggests the first may be the case, but it may be

the second, which is more worrying from my point of view.

*> *Executing* MMa code is a bit messier; you need a program*

*> transformation system to do pattern-match/rewrites to implement*

*> much of the semantics. And of course of your code contains any*

*> complicated formulas needing simplification,*

*> you might need all of MMa proper to provide the necessary*

*> set of rewrites that encode all that math knowledge.*

Yes, I am aware of that. My thoughts are that if one could get to the

point of being able to parse the input, making it open-source, then

others would be able to improve it by encoding at least a subset of

the maths knowledge. Realistically, it is not going to be possible to

make a fully functional Mathematica clone.

*> FWIW, our DMS Software Reengineering Toolkit (a program*

*> transformation system)*

I was looking for open-source solution, to make an open-source

alternative to Mathematica.

*> Ira Baxter, CTOwww.semanticdesigns.com*

Thank you Ian

Dave

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.