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

[William Sit]

"Page, Bill" wrote:
> 
> On Wednesday, June 22, 2005 11:55 PM Andrey G. Grozin wrote:
> 
> > ...
> > Only the user can decide *which* consistent state [s]he wants.
> > Suppose there is a code fragment:
> >
> >   (1)   n:=1
> >   (2)   x:=f(n)
> >   (3)   n:=2
> >   (4)   y:=f(n)
> >
> > Do you consider the state of Axiom after it inconsistent?
> > I don't. This is an imperative language, after all.
> 
> I agree with you. The state of Axiom after executing this just
> this sequence of commands would be consistent by definition.
> "Consistent" means that the commands have been executed in the
> order implied by their appearance on the page. I have added line
> numbers such as (2) for reference.

I don't agree that consistency is a desirable feature for a 2D editable
interface. But for the sake of discussion, in this model, the screen is an
infinitely long sheet and the location where one enters or edits a command line
is important. 

But why don't we separate the issue of lazy re-evaluation from the editing and
display issues? I would prefer to visualize the state of the screen as a batch
file. After editing this batch file (don't care how), you want to minimize the
recomputation so that the results are as if the batch has been re-executed from
the beginning to end in a fresh session. So this is the full roll back model I
discussed in Part III.


By definition, when a batch file is run, the system is consistent.

> > If the user edits the first line to read:
> >
> > (1)   n:=3
> >
> 
> As soon as the user edits the first line, 
> the current contents
> of the page displayed page is no longer consistent with the
> the current state of Axiom. 

This is temporary, and has nothing to do with LRE. If you run the new batch
again, it would be consistent. The problem is not restoring consistency, but
rather deciding what computations may be avoided, if the system cached the rhs
values.

> In order to restore consistency ... [what to re-evaluate snipped]

If the LRE algorithm is clever, then it need not evaluate (3') and(4') but
evaluate the rhs of (1') without binding it to n, evaluate only f at the result,
and binding that to x without changing the state of n (which remain having a
value of 2), and display the rest (or leave them alone).


> And now the state of Axiom is consistent with the appearance of
> the page again.
> 
> > I'd hate it if the system would make such decisions for me.
> 
> I don't understand. This is exactly the same decision that
> you just said that you would have made.

Come to think of it, that is what spreadsheet did all the time. (Now I get the
connection to spreadsheet).

It should not matter to the user how LRE works and I would now agree that LRE
has a role to play. However, this should be done for batch mode files, not
interactively on screen, because then each edited line will cause the system to
maintain consistency, causing unnessary re-evaluation perhaps. In the roll back
model, the user is only concerned with the results of a batch file. In the
interactive environment, there should be a button to activate re-evaluation
(much like a spreadsheet) and an option to have this as default or not.

If the user makes substantial editing, including rearranging order of lines, it
would make LRE harder. Also, if a user is simply exploring some what-if
situation, the system automated changes in related values may not be desirable
when these are statically bound. In general, I do not like that the result of a
command depends on its screen location.

William