Re: Iterators/Apply-qualifiers in MathML 2.0(content)

> 	I have one suggestion about the opportunity to qualify apply
> in MathML.
> Remark 2:
> 	Meanwhile, there is a need for a general "iterate" primitive
> (maybe not the best name). Which iterate any operation on variables,
> like in the way apply does it with qualifiers ( Such an operator
> would have the advantage of caring of the iteration in place of the 
> operator itself. As an example, it is perfectly legitimate to apply 
> an iteration to:

I agree with you that such a thing is needed in MathML, but I think
another solution to this problem that I proposed earlier on this list 
would both be cleaner and more natural to mathematicians.

For this purpose I suggested in an earlier message to allow the <bvar> and
<condition> qualifiers to appear in any apply.  The intention was to have
the default semantics of an 

      <condition> ... </condition>

be what you call the iterator of the construct, similarly to the way many
iterators are represented on paper by a "big" version of their binary
operator representation.

This solution has the following advantages:

  -- no need to introduce yet another constructor
  -- realizes all(?) the "iterator" constructs' intention
  -- easily generalizes to default semantics for, say, unary operators
  -- easily generalizes to using possibly structured operators
  -- easily generalizes to using operators that can only be used
     with <bvar>s (such as new quantifiers)

Note also that the <interval>, <uplim>, and <lowlim> qualifiers are
special cases of the <condition> qualifier, so that it may not make sense
to use the former in a more general setting than strictly necessary.

Unfortunately, all four of these qualifiers (with the exception of the
<condition> qualifier) have a fundamental problem that I pointed out
more than two years ago, which your <iterator> solution fails to solve:
                          the scopes of these qualifiers are *outside* 
the scope of their corresponding <bvar>, while other arguments of the
<apply> (or <iterator>) are *within* its scope (see my message of November
1998 for details).  This makes for a very unclean design, and is the
reason why OpenMath opted *against* including such qualifiers, requiring
instead that operators such as <int> be functions that take
functional arguments (plus the set that the argument function ranges over
as a second argument; see example below).

The <condition> element explicitly is *within* the scope of its
<bvar> according to the MathML definition, so its use is much cleaner for
a general semantics than the general use of the other qualifiers.

Unfortunately, restricting oneself to the <condition> and <bvar>
qualifiers makes it impossible to specify, say,

  int(lambda(x,sin(x)), [0..x])

the way OpenMath defines it (note that int here is a function
taking a function and a set as arguments!).  But that is probably no
problem since it is easy to specify different semantics for an operator
with the same name and a different signature ( (set,function) ->... ).

BTW: Does MathML 2.0 as it currently stands allow the equivalent of 

    int(f, D)     

with f and D content identifiers (f a function, D a set) with the
semantics of an integral of the function f over the domain D, without
introducing a spurious variable x and writing the equivalent of

   int(f(x) dx, x in D) ?

I think I pleaded those two years ago or so that this be allowed in
compatibility to OpenMath, but I'm not sure it is any more.


          Andreas Strotmann