Update on MINSE

First let me say that i'm very glad to have the opportunity
to be working with such a distinguished group of people 
on something so significant.

------
Here is the update: an operational renderer to text
is now available on the site

    http://www.lfw.org/math/

You can now insert expressions into your documents
once, and expect them to be appropriately rendered
for both graphical and text-based browsers.

------
The more i look at the problem and think about what this
group has discussed, the more similar our approaches seem,
and the more it appears to me that MINSE might actually be
very close to what we want.

Its lexical analyzer is very similar to the one proposed
by Dave Raggett in [035].  The parse trees are represented
in a LISP-like fashion, similar to the way it looks like
this group has been thinking about them.  The only major
conceptual difference is that MINSE aims to be less math-
specific, and separates the notation definition from the
style definition.  It also has a ready-to-use extension
language -- Python.  (Python can be told to run modules
in restricted execution environments if were are downloading
styles and notations off the Web.)

I hope to have downloadable extensions working quite soon.
The text renderer is already implemented as a separate
"style" module.

The current implementation of MINSE is lacking with respect
to some of the thoughts of this group in the following ways:

    - It doesn't do generalized template matching.  It
      just deals with operators, but you can define whatever
      operators you want.  Allowing template rules causes
      problems with cascading notation definitions, as i
      mentioned in the message about parsing.

    - It doesn't do macro expansion (yet), but this will be
      implemented soon.

    - There isn't a way of directly representing operations
      performed upon operators.  I believe the way to do this
      would be to allow, in the internal representation,
      lists as well as atoms to take the first position in
      a list.  I think it is quite feasible; a possible way
      to add this to the syntax is to write .(sum;n) to
      qualify the addition operator with the letter n, for
      example -- this is natural because the period is used
      currently to introduce operators.

      Is operator-operator binding something that will ever
      need to be carried to an indefinitely deep level?
      As in operating on operators the operate on operators
      that ... etc.

    - You can't redefine what parentheses do.  This may be
      possible to change if template matching is added;
      however, i think it's probably a good thing to have
      some elements of fixed syntax.  Grouping and argument
      collection are quite basic, and it is possible to
      express everything you need without redefining what
      parentheses do.  If you want an open or a closed
      interval, just use a compound.

On the whole, i think that these aren't very serious flaws;
it also has the advantage, of course, that the implementation
exists at all.  Interest is gathering among educators on the
Net.  I think it is a reasonable place to start.

In any case, i shall proceed to brace myself for criticism.
Fire away...


[035] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00035.html


Thanks for reading,


Ping