From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 20 Nov 2006 01:27:08 -0800 (PST)

Message-ID: <3132.217.124.69.196.1164014828.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Date: Mon, 20 Nov 2006 01:27:08 -0800 (PST)

Message-ID: <3132.217.124.69.196.1164014828.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

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 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:59 GMT
*