Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI)

[William Sit]

Bill: 

To avoid really long messages and also to focus on issues separately, I'll
answer yours in several less long ones. 

This is Part I: hyperdoc evaluations

"Page, Bill" wrote:

>  [information on lazy-evaluation, delayed-evaluation, lazy-re-evaluation 
    snipped]

Many thanks for a quick education on these.

> > The above delayed evaluation (which is automatically evaluated when
> > needed) only occurs *after* the SetDelayed or macro definitions have
> > been executed earlier (known the Axiom's run time system). This is
> > different from the hyperdoc browser, which may have only *read in*
> > the input file, but *not yet* run any assignment (delayed or otherwise).
> > This is like in Mathematica when the you read in a Notebook, commands
> > are not executed (unless marked as initialisation cells and the
> > system set to automatically run these on loading). Now if a user
> > *skipped* some assignments (delayed or otherwise) that, say, defines
> > x, y, and *jumped* to an assignment for z that involves x, y, normally
> > in the Axiom interpreter, the x, y would be treated as undefined symbols
> > and perhaps cause either a syntax error or a wrong evaluation. In
> > hyperdoc, the system will know whether x and y are free or bound
> > (because these are declared in the input file when it is built for
> > hyperdoc from regular input file), it knows to search for their
> > definitions and execute those assignments.
> 
> I don't see any difference in principle between a 'bound' variable
> in hyperdoc and a delayed evaluation in Axiom. In both case the
> definitions are "read-in" but not yet acted upon. It's just that
> this is occurring at a different level in the system. There is a
> difference however in the case where the command in Axiom is not a
> delayed evaluation. In effect in this case the value of a variable
> is being updated ("cached" i.e. stored) and should not have to be
> evaluated again.

There is a difference, at least, observed difference. In hyperdoc's case,
"read-in" means merely it was read in for the purpose of displaying it, not
"read-in" by Axiom (that is, hyperdoc has not passed the information to Axiom;
in Mathematica, that would be the FrontEnd has not passed the information to the
Kernel). If you try in the hyperdoc browser:

Examples->Domains->OrderlyDifferentialPolynomial and scroll down to the button
next to w.5, click it

then a new frame is started, and the buttons above the one clicked are examined
for dependencies to evaluate w.5, in this case, these are sent to the Axiom
frame for execution (now "read-in" *by Axiom*):

dpol := ODPOL (FRAC INT)
w:= makeVariable('w)$dpol
w.5

Note that the line 

z:= makeVariable('z)$dpol

which has a button and placed right after the second line above and before the
third line (w.5) above in hyperdoc page, is *not* passed to Axiom Interpreter.
Indeed, if you now type

z 

in the frame, you get

(4) z      Type: Variable z

Now I don't think this is anything sophisticated to implement (these are short
files, so efficiency is not a problem, we can do a brute force search for
dependencies), but it is not entirely trivial either, and makes it convenient
for the user to be able to click any button without worrying about omitting some
buttons in a sequence. It is the equivalent of selecting a sequence of (perhaps
non adjacent) cells to execute except that the selection is automatic.

> > So the hyperdoc action, as I understand it, is unrelated to
> > "lazy re-evaluation" of the first paragraph.
> 
> That is correct. 

I would now revise my statement:

So the hyperdoc action, as I understand it, is unrelated to
"lazy evaluation" of the first paragraph since all it does is selecting a subset
of commands to pass onto Axiom.

William