Re: Content MathML editing language: Binary => n-ary syntax

Andrew Miller wrote:

> I am also seeking opinions on the most intuitive way to deal with the
> conversion between binary in-order operators like +. For example, if,
> within the input language, you have
> x = a + b + c + d + e + f
> a naive parser might create MathML like...
>
> <apply><eq/>
>   <ci>x</ci>
>   <apply><plus/>
>     <apply><plus/>
>       <apply><plus/>
>         <apply><plus/>
>           <apply><plus/>
>             <ci>a</ci>
>             <ci>b</ci>
>           </apply>
>           <ci>c</ci>
>         </apply>
>         <ci>d</ci>
>       </apply>
>       <ci>e</ci>
>     </apply>
>     <ci>f</ci>
>   </apply>
> </apply>
>
> A slightly more complex parser might instead produce:
> <apply><eq/>
>   <ci>x</ci>
>   <apply><plus/>
>     <ci>a</ci>
>     <ci>b</ci>
>     <ci>c</ci>
>     <ci>d</ci>
>     <ci>e</ci>
>     <ci>f</ci>
>   </apply>
> </apply>
>
> I would be interested in opinions on whether you feel this automatic
> translation from multiple binary in-order operators to a single
> pre-order operation makes sense (note: all CellML tools available now
> work with real numbers only, but future work could allow it to be
> extended to support other mathematical constructs. Using a definitionURL
> on an operator is technically valid CellML, but no tools can do anything
> with this either).

If you are generating an input syntax for MathML and the more correct
expresion in MathML uses n-ary, then it looks natural the last form.

However, I do not find a good idea the use of infix as input syntax for a
prefix data structure. Input syntaxes *may* mimic the internal structure
of language. If that is not the case, you find problems -specially at
advanced usage of the language capabilities-.

This has been the problem of using TeX, LaTeX, ASCIIMath, ITeX... as input
syntaxes for p-MathML.

This is also the problem of using infix notations for LISP. You cannot
enter "a + b" if internal representation for your language is (+ a b).
During many decades very smart people has tried to develop infix notations
for prefix LISP and always failed to conquer.

The natural input syntax is

(= x (+ a b c d e f))

or better

(eq x (plus a b c d e f))

Any other option will be either a proof that initial MathML design was
wrong [1] or will generate the same class of problems to advanced users
that infix notations generate to LISP users [2].

If your language is prefix, it has no sense generation of an infix
notation for it. If you take another way and continue this, in the end we
will revive difficulties of the infix notations developed for LISP
(prefix) during last decades.


Notes:

[1] If you claim that prefix notation has many many advantages over an
infix notation -e.g I heard is easier for parse and identifies the
operator in unambiguous way- but after you enter the data with an infix
notation... cof! cof!

[2] E.g. the CAR of the infix input syntax is not the same that the CAR
for final data structure, therefore, even if you type in infix, you may
think in prefix. You may think in infix and prefix at the time of writing
symbolic expressions.

Received on Monday, 20 November 2006 09:27:19 UTC