[Axiom-developer] RE: More AxiomUI

[Page, Bill]

> ...
> Am 20.06.2005 um 22:05 schrieb Bob McElrath:
>> I've also been thinking about the worksheet interface.  One of
>> the main drawbacks I see is the concept of "state".  The server
>> has some state that is different from the worksheet state.
> ...

On Tuesday, June 21, 2005 7:00 AM Kai Oliver Kaminski wrote:
> That's why I proposed to create a GUI backend in Common Lisp.
> The browser is abused as a portable GUI framwork with scripting
> support. Javascript will only offer convenience features like
> nicer input, communication without page reload etc. The heavy
> lifting will be done by the backend. Axiom's output to the
> backend would not be, as some people imagine, geared towards
> presentaion but towards presering the semantics. That way the
> backend can do dependency tracking between different expression
> and automatically update pages or parts of them if necessary.

It is certainly possible to do "dependency tracking" as part of
the "back-end" process separate from Axiom - more or less the
same way it is done in the Axiom hypertex browser now. But why?
It is Axiom's job to understand Axiom command syntax and semantics.
If it isn't already done, it seems to me that the most logical
place to deal with the dependencies between Axiom commands is
in Axiom itself. Axiom already has a powerful )history command.
It is the state of Axiom's objects compared to the state of the
browser display that we are worrying about. Adding a layer in
between just seems to make this more complex.

Since Axiom is a very high level language allowing functions as
first order objects etc, doing this reliably and automatically
outside of Axiom seems very difficult to me. Having to mark each
variable as either \bound or \free in each command (as in the
current hypertex browser) seems very awkward. Therefore I think
what we need is function within Axiom that the browser interface
can call which will list those Axiom commands which depend on any
Axiom objects that we have just re-defined.

>> What if I could select the result of an expression and click on
>> "simlify" or "combine these terms".  The interface could insert
>> the relevant commands in the same execution block as I just ran,
>> *without* recomputing that block.  e.g. if I sequentially apply
>> "combine these terms", "factor this", etc.  I should be able to
>> in-place simplify by hand, and *also* have the execution block
>> reflect those operations.
>>
>> For example:
>>
>>> integrate(something complicated, z=0..1)
>>
>>     hideous output
>>
>> When I click on sub-expressions in "hideous output" it would
>> insert the relevant operation such as "simplify(%)" just below
>> "integrate", such that if I re-execute that block it looks the
>> same as it does now.

What Bob describes is much better than what is possible now on
Maple. It is possible in Maple to "click on sub-expressions" and
to paste the corresponding sub-expressions back into Maple as
input but this does not create any permanent "relevant operation".

>>
>> FYI this would never work in Maple, since it uses non-
>> deterministic expression sorting...the first term will not
>> necessarily be the same upon subsequent evaluations, so
>> "simplify(op(1,%)+op(2,%))" will not necessarily be operating
>> on the same terms.  I don't know if Axiom has this same disease...

Actually it is usually possible in Maple to do this using
operations like select() which selects sub expressions based
on their content instead of their "position" like op(). But
that is not really the point.

I think you will find that Axiom has a rather different "disease"
(or maybe it's a mutation with some advantages as well):

For the most part Axiom really does not have any uniform notion
of "sub expression"! For example Tim Daly wrote:

"Axiom does not use a tree representation in general although
particular types might."
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00039.html

"The issue was how to correctly perform simplification. In particular,
we'd like to raise simplification to a user controlled level rather
than keep it embedded in the interpreter."
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00040.html

Related: "... the differences between Axiom's approach and a
tree-based approach like in the three Ms." (Dylan Thurston)
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00035.html

>
> If Axiom is able (after possible modification) to give unique 
> identifiers to the subexpressions this should be possible, if
> tedious to implement.

I think this might be quite hard. The modifications would perhaps
be similar to what Tim described in axiom-math/2003-10/msg00040
above:

"Suppose we try a naive approach. We could decorate each domain (those
parts of Axiom which have an internal representation) with a function
that would return the internal representation recursively expanded
into a lisp s-expression. We could also give each domain a function
that takes this s-expression and tries to simplify it. But we run into
an issue. What would be the return type of such a simplify function?"

Regards,
Bill Page.