Re: Technical reasons for some options taken on design of MathML

Andreas Strotmann wrote:

[snip]

> Actually, the first two drafts of MathML (late 1997, Jan 1998) used the
> latter form (<expr> 5 <plus/> 8</expr>), but with the third (Feb 1998)
> draft, MathML Content shifted over to essentially the current form. I
> seem to recall some comments as to the reasoning behind this shift from
> members of the committee back then, but they may have been personal
> communication rather than messages on the mailing list. Still, if you're
> really interested in the reasoning here, I would recommend comparing
> those early versions - before and after the shift - and you will
> probably see the reasoning spelled out if you read between the lines a
> bit. You will probably find that those things you can find this way are
> still being said in the current version of the standard, but you may not
> realize immediately that they directly address this question.

Yes I am aware of that early infix way, I am also aware that committee
members did not agree on Content MathML and claim that Content version was
“not well thought”.

Therefore, I believe that nobody has really explained why of the use of
final Lispy form. What are advantages if any?

> That said, I was told back then that there had been unofficial reasons
> for this shift, too: quite simply, over the decades, people in the field
> of computer algebra had learned how to design semantically oriented math
> languages, and it was people from this field who were instrumental in
> designing Content MathML. They quickly realized that implementing and
> using the infix version of Content MathML was excessively quirky and
> bothersome, and quite naturally switched over to the clean prefix
> operator / generic apply model that pretty much all computer algebra
> systems - the ones that will process Content MathML - had been using for
> good reasons all along.

I can understand that prefix operator can be a bit easier for the computer
but is not easier for authors, not for programmers. That is reason that
almost any hand calculator, computer package, or programming language do
not use prefix notation.

Fortran for example, introduced infix notation for computer algebra and
this was followed by C, Mathematica, Maple...

It is more, XSLT uses infix notation for math! How is possible that the
*same computer* can perfectly understand something like a+b*c in a XSLT

<numbers>
  <x>4</x>
  <y>3.2</y>
  <z>11</z>
</numbers>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     version="1.0">
<xsl:output method="xml" omit-xml-declaration="yes"/>

<xsl:template match="numbers">
  (4 + 3.2) * 11 = <xsl:value-of select="(x+y)*z"/>
</xsl:template>

</xsl:stylesheet>

but needs (* z(+ x y)) in Content MathML?

Is not this excessively quirky and bothersome?

Moreover that “a bit easier” of above is also debatable. It is a bit
easier if you are not obligated to present result (or receive input) in
infix notation, since then you may develop a translator macro
/infix/prefix/infix. And computer life becomes harder!

What is more some programmers claim technical advantages of the use of
postfix notation, then if the argument was easier the computers life, why
do not use postfix notation (x y +)?

>  -- Andreas

Juan R.

Center for CANONICAL |SCIENCE)

Received on Friday, 31 March 2006 14:17:28 UTC