Re: Some new basic thoughts for MathML 3

David Carlisle said:
>
>> More natural choice for c-MathML is LISP,
> some people, including me!, like lisp syntax but in over 40 years of use
> it has constantly failed to be popular with the public.  One of the main
> reasons given for dsssl failing ever to be really popular was its use of
> scheme lisp syntax. It's immediate descendent, XSLT which uses a far more
> verbose XML syntax has ended up being perhaps the most successful new
> programming language introduced in recent years and is probably the most
> widely installed programming language ever. (it's hard to install
> windows or linux, or mac os without ending up with at least 1 and
> probably 2 or 3 XSLT implementations).

Most successful? XSLT has been broadly rejected at the programmer’s side
and, in despite of benefiting from the XML-W3C hype and of the lack -until
recent times- of adequate tools for transforming XML docs, the TPC index
(popularity) for XSLT has always remained very close to the absolute zero,
whereas languages as Javascript, PHP, or Python continue being very, very
popular and increasing.

The August 2006 TPC index for XSLT is less than 0.070% and, in your own
words, the "successful new programming language" is not even listed
between the 50 first ones; Javascript is 10th in the ranking with a 2.019%
of popularity; PHP is in the 5th position with a 9.639% [1].

Next popular language will be probably e4x. Last Firefox browser has
already got native support for e4x and this is a hard knock for
client-side XSLT.

> So while it would be useful to have a lisp input syntax with a standard
> tool for expressing it as XML for authoring use in environments where
> that makes sense, I don't think that a lisp based syntax should have
> been or should be now, the normative syntax.

>From your writtings I suspect that you will vote for a non-LISP input
sintax for c-MathML. In your above "review" of LISP history you forgot
that during "the 40 years" any of the attempts to provide a non-LISP input
syntax (including MIT’s MLISP) failed.

The main reason for the long-term failure is that using an infix syntax
for authoring -e.g. 2+3- whereas a prefix notation for the internal data
representation -e.g. (+ 2 3)- generates more disavantages and headaches
that when directly using the prefix notation for authoring the code.

In fact, initially I designed an infix notation for c-MathML, but would be
so unpopular as infix notations were for LISP during "the 40 years"
because you need work with two incompatible representations. Then either I
would abandon the infix input notation or I would abandon the prefix
c-MathML data model. I abandoned the latter but this option is not
available to MathML people, true?.

Of course, you are free to vote for a non-LISP input syntax for the
LISP-like content MathML data representation.

>> (the use of TeX or dialects
>> as Itex in MathML 2 has been one of greatest mistakes when authoring
>> online docs).
>
> The use of TeX-like synax for authoring is to enable those
> people familiar with that syntax to easily author expressions (or to
> easily convert existing expressions). Offering people a new syntax they do
> not know does not help with either of those aims. That's not to say it's
> not useful in itself, just that a TeX-like input syntax or, related,
> conversion from teX to MathML, will still be needed even if a conversion
> from a lisp synatx was also available.

You would not confound "TeX-like syn[t]ax" with "TeX or dialects as IteX"
(it was I really said).

One can generate a consistent extended _TeX-like syntax_ without using
limited TeX or IteX systems. Look for instance at next site [2] if you
want obtain _some good ideas_ for the input syntax of the next p-MathML3.

Instead writing pure nonsense [*] as {}^{b}X in TeX or IteX tools
(generating a completely wrong MathML code, structurally invalid, with
very poor both accesibility and searchability, and often incorrect visual
rendering because size and positions of scripts are computed via a wrong
base), you would write

\sur{b}X (or similar!).

Extensions of that kind (completely needed if you want use MathML or
XML-MAIDEN properties are not supported by old TeX) are, however,
complemented with _standard_ LaTeX:

Base_s
Base_{sub}^{sup}
\frac{numerator}{denominator}
\stackrel{over}{Base}
Etc.

Fortunately, the author of [2] is now in the new MathML WG and I wait
something minimally usable and consistent for the next MathML 3.

>> I find surprising that MathML 2 uses prefix notation
>> for 2/3 but infix via <sep/> for rational numbers.
>
> yes so do I, something that perhaps should be looked at again as part of
> mathml3, obviously we can't remove sep but I do agree that it is one of
> the more awkward parts of the language, and perhaps mathml3 can have
> some other alternatives that fit more naturally into the system.
>
> David

There is not need to remove <sep/> if you want maintain backward
compatibility.

<apply><rational/><cn>12342</cn><cn>2342342</cn></apply>

or alternatives you can imagine

<apply><type-rational/>...

<apply><rationalnumber/>...

<Etc></Etc>

can be defined to be "equivalent" to MathML 2

<cn type="rational">12342<sep/>2342342</cn>

Current half-dozen of c-MathmL tools can write the ugly <sep/> whereas a
future MathML 3 tool would prefer the new approach (whereas understanding
the MathML 2 one).

My early suggestion to improvement of reals [3] would be retyped as
_something close to_

<apply><complex-polar/>
  <cn>2</cn>
  <apply><real>
    <cn>3</cn>
    <cn>1415</cn>
  </apply>
</apply>

with natural LISP-like input syntax (or alternatives the WG can imagine):

(complex-polar 2 (real 3 1415)).


[1] [http://www.tiobe.com/tpci.htm]

[2] [http://my.opera.com/White%20Lynx/blog/show.dml/256124].

[3] [http://lists.w3.org/Archives/Public/www-math/2006Jul/0083.html]
    [http://lists.w3.org/Archives/Public/www-math/2006Jul/0090.html]


[*] The ANSI/NISO/ISO 12083 (1995) says:

<blockquote>
The stagger attribute is a way to get rid of the meaningless, and
undesirable, zero-width element <zw> (which probably originates from TeX’s
{}, which is used to code the above example as H^1{}_2{}^3).
</blockquote>


Juan R.

Center for CANONICAL |SCIENCE)

Received on Monday, 14 August 2006 12:55:46 UTC