axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bob McElrath
Subject: Re: [Axiom-developer] Consistency (was Lazy Evaluation)
Date: Thu, 23 Jun 2005 03:03:20 -0700
User-agent: Mutt/1.5.6+20040523i

William Sit address@hidden wrote:
> Come to think of it, that is what spreadsheet did all the time. (Now I get the
> connection to spreadsheet).

I think that is the best analogy.  Mma/Maple are really a poor editor
interface for dispatching out-of-order commands to a behind-the-scenes
kernel.  Their kernels (and axiom's) are best viewed as a batch system.

But (I think) the front-end might be better viewed like a 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.

I completely agree.  I would personally mark output blocks when it is
known that they need to be re-evaluated.  An option could turn on forced
re-evaluation.  Personally, I would not turn that on...but students
working on relatively simple worksheets would probably like it.  Also I
think each output block should keep timing information.  The kernel
could intelligently decide not to re-evaluate something that took 10
minutes last time, but go ahead and re-evaluate things that took 10 ms
last time.

I've had a visual of a CSS <div> in a browser, and just turning the
background pink, with a little "re-evaluate" button in the UR corner,
and a "re-evaluate all" button somewhere in the interface.

> 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. 

After substantial editing is also when humans tend to fail to figure out
what needs to be re-executed.  If the whole sheet is red because the
user rearranged everything, then so be it.  It all needs to be
re-evaluated.  A human cannot figure out dependencies any better than we
could, algorithmically.

There is nothing a human knows about state that we cannot determine by
looking at the sequence of commands.

> In general, I do not like that the result of a command depends on its
> screen location.

This is in violent opposition to the example suggested earlier by
Andrey:
    n:=1
    x:=f(n)
    n:=2
    y:=f(n)
A perfectly reasonable thing to do, and the result *absolutely* depends
on screen location.

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.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "One of the best ways to get yourself a reputation as a dangerous citizen
    these days is to go about repeating the very phrases which our founding
    fathers used in the great struggle for independence." --Charles A. Beard

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]