On Sunday 14 September 2008 01:27:43 pm Richard Fateman wrote:
> Allow a user to translate a mathematica definition (in a file) into a
> maxima definition (also in a file).
>
> This could access the mma-compatibility functions as needed, use similar
> programs with different names, as needed, print warning messages like
> (Solve and solve are not really the same; Limit and limit are not really
> the same...)
>
> and there might also be occasional runtime messages from the translated
> code as
> well.
>
> A parser for the mathematica file is available (mockmma) in lisp.
>
>
> One advantage to this approach is the "translated" file can be examined as
> a tutorial of how to talk mma-ish in maxima.
I have been having some success playing with the perl module
Parse::RecDescent (I know I should use CL, or python, or
..., but I don't know those, and I have a lot of experience
with perl regexps.) But, I wonder to what extent the Mmma
grammar is compatible with an LL parser generator and what
problems that might cause. I'm certainly not committed to
Parse::RecDescent; its reputed to be very flexible and very
slow. I just downloaded mockmma, and I'll look at it. For
myself, not being a lisp guru, I like the idea of using a
parser generator with a user base for support, but I don't
know how important that is.
Anyone else have opinons on parser generators?
It would be easiest to first parse Mma FullForm and
translate to something equivalent in Maxima ( eg. "*"(2,3) )
and then add support for infix operators later. I'll
generate the FullForm code when I get access to Mma, but I
can't now. For now I have been working on building a tree in
the natural form (FullForm) and flagging operators to note
wheter they were infix'ed in the source code, so that a choice
can be made as to what to do on output.
There is some flexibility in how things are done. ie, one could
write the Mma For[,,,] construct in Maxima or translate it
to "for i thru ... " with the parser.
John