RE: [Axiom-developer] Consistency (was Lazy Evaluation)

[Page, Bill]

On Thursday, June 23, 2005 6:52 AM William Sit wrote:

> In general, I do not like that the result of a command depends
> on its screen location.
>
> Bob McElrath wrote:
>> A worksheet is read from top to bottom, as a document, not a
>> batch-system-dispatcher.  As a document, it should make sense
>> if I read it in order.  The idea that a command's result is
>> independent of its screen location forces the user to keep
>> considerable state information in his head.  By putting the
>> state information into the document, in order from top to
>> bottom, the user is freed from having to keep *any* state
>> information in his head, because he can simply read it off
>> the document.
>

Yes, that's it exactly!

I think this view is very much in keeping with the intentions
of Axiom's original designers. Axiom was originally called
"ScratchPad" (written with a internal capital letter just like
WikiWord, still ahead of it's time). Hmmm... that gives me an
idea:

Why don't we name the *new* Axiom user interface ScratchPad?

Anyway, I think the type of user interface we want should be a
kind of "intelligent" scratch pad, not just a plain dumb old
piece of paper. If I erase something that I previously scratched-
in near the top of the page and replace it with something better,
I want my intelligent ScratchPad to be able magically re-assemble
itself as if that was what I had written all along. No more,
rewriting, crumpling up old pages, and throwing them in the
waste basket.

It would be even nicer if it could warn me more gently using
shading and color that my change is going to affect two or
three others things way down near the bottom of the page but
not anything in between. These in between calculations were
ok and don't need to be re-done. But the other things might
need more attention or maybe they just need to be repeated
rotely with some simple substitution of values or symbols.

> I don't disagree that most *finished* worksheet read from
> top to bottom, and the commands run from top to bottom, but
> that need not be the norm. Document is a good analogy: modern
> documents are not linear, because we now have hyperlinks;
> we can, and want to, skip around! A program is the same,
> the code need not be linear in structure: we may have parts
> A, B, C in parallel followed by D that depends on A, B, C;
> code can even have a circular structure (like Axiom
> domains). Compilers do code optimization by exploring the
> non-linear structure of the code.

I think that that is a very good point.

The "Intelligent Paper" (tm) described above is one kind of smart
user interface, but you are right that the way we use the web
and other smart document interfaces these days is gradually
changing the way we view what used to be limited by the nature
of the recoding technique on ordinary paper. To work in this
new way, we need to be able to "navigate" easily and fluently
through a network structure in a sort of multi-dimensional manner.
This is exactly what excites so many people about the Web.

So I agree completely that the new ScratchPad needs to be very
much aware of and integrated with the (still evolving) Web point
of view about organizing pages into a very dynamic kind of
"document", i.e. web site. What Tim Daly calls "Doyen" is exactly
this kind of web site - a kind of Public ScratchPad. The Axiom
MathAction web site is a kind of prototype for what Doyen should
eventually become. We need the new personal ScratchPad to
integrate smoothly with this Public ScratchPad. This is the way
that private mathematical "work in progress" may someday be
published and shared rapidly with others.

It seems to me that right now the planets must surely be in
a favorable alignment since we seem to be recognizing this
need for a new approach just at the time that exactly this
new kind of web technology is being experimentally developed.
For example I think we can learn a lot from this project:

http://www.tiddlywiki.com

Bob McElrath already has a version of this web interface
that provides pretty mathematics in addition to all of the
other editing and hyper linking features:

http://bob.mcelrath.org/tiddlymath/tiddlyjsmath.html

I think that for people who are already comfortable with this
new multi-dimensional hypertext way of writing and working as
one of their own personal tools, we also need to be able to
provide this kind of flexibility for the new ScratchPad user
interface.

> During development of this final product, just like writing
> any essay, we gather together ideas, pieces, expand them,
> rearrange them, put them into sections, chapters. Until the
> document is finished, it is *not* consistent! The state of
> consistency is approached only gradually.

That is certainly one way of working that we need to accommodate.

Another approach that is perhaps more popular among computer
programmers than it is among mathematicians is a kind of iterative
approach. In this way of working one strives to always maintain
one's creation in a consistent state. Programs are dynamic things
that have complex and sometimes apparently unpredictable behaviors.
In order to place some bounds on the amount of complexity that
we have to deal with, we often write programs in small iterative
steps. First a very simple version of the program is written that
does some basic things - makes certain limited calculations - but
does them right and consistently. Next we begin to make small
iterative improvements, testing each improvement in an attempt to
ensure that we have not "broken" anything by our changes.

I think that as more and better computer tools become available
for mathematics, more mathematics may actually be done in this
way.

> So in developing a computation worksheet, as I often do in
> Mathematica, I start with exploratory routines, test ideas,
> revise, expand, change, etc and finally reorganizing this
> into a logical sequence of commands. The entire sequence is
> not necessarily linearly ordered, as the location of some
> functions (especially those defined with SetDelayed, which
> I would consider as library functions) are unimportant except
> for grouping into some theme. The main executable (using
> immediate assignments) sequence would be linear mostly.

What you are describing reminds me very much of the literate
programming style that was promoted by Knuth and which Tim
has adopted so whole heartedly for the Axiom source code.
Literate programs a complex documents which can be processed
and viewed in several different ways. Most notably there is
the "weave" view of the document which is most similar to
a paper-based kind of publication. But there is also the
"tangle" view that is necessary to extract the programming
code for the computer.

I agree that this kind of flexible multiple views of a
single complex object is probably also a very good paradigm
to adopt for literate mathematical programming, i.e. what
most people want to do with Axiom.

> Why should I need consistency during the development? If
> I am only working on some single subroutine, why shouldn't
> I be able to test this in isolation?

To my mind these are two very different things. We need
consistency during development in order to help manage the
complexity which otherwise could very easily overwhelm our
limited human abilities.

Yes, testing and working with smaller pieces of a mathematical
calculation, or proof, or program, is often best done in
a isolated more controlled "environment". Programmers often
set up special "test harnesses" which are special programming
environments specifically for isolating and testing specific
features of some new piece of code. This is very similar to
the practices in other types of engineering and also in
experimental sciences. In engineering terms this is usually
called "unit test". It is one important step in the development
of complex systems.

I agree that the new ScratchPad user interface should be able
to support this kind of use.

> If I keep track of dependencies with SetDelayed, there is
> no need to worry about the eventual consistency. Even if I
> can place code in  a linear space order, why can't I prefer
> just a linear logical order? All I need is consistency of the
> final code, which if it works, is automatic.

"which if it works, is automatic" ... that is the common
presupposition of many less experienced computer programmers
and software development companies with whom I have worked.
They are often very reluctant to become involved in system
testing and business case scenarios because they usually feel
like this a waste of time since they have already shown with
there unit tests that everything "should" (implying that it
"will") work. But in every case that I know of, these people
have been wrong. There is a whole computer science literature
on this subject.

> For developers, it is the revision cycle that is time
> consuming. I would like to have all the freedom available.

Reducing the revision cycle time is exactly what lazy
re-evaluation is all about. I don't think that it needs
to restrict your freedom in any way.

Regards,
Bill Page.