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

[Bob McElrath]

First let me give a simple definition of lazy re-evaluation.  Imagine a
worksheet interface, that when read from top to bottom, is *always*
consistent.  In Maple and Mathematica the user must remember what he has
executed, and keep much information about the kernel's state in his/her
head.  It is very easy to miss that an output block has changed and
should be re-evaluated.  This state information is easy to keep and deal
with in axiom itself, and would *never* make mistakes.  A user with a
1000 input worksheet will surely make a mistake about which output lines
need re-evaluation sooner or later.  I certainly do.  But then, I'm a
world-renowned software-breaker.

William Sit address@hidden wrote:
> I am not sure what you meant by "lazy re-evaluation" here (or it could be my
> ignorance about the concept). Mathematica has two modes of assignments:
> SetDelayed (:=) for functions and Set (=) for immediate evaluation and so does
> Axiom: macro (==) and assign (:=). Both SetDelayed and macro can be used to
> define *any* identifier, not necessarily a function (just think of it as
> function without arguments although there may be a minor difference: "x == 
> ..."
> instead of "x() == ..."). Each time an identifier defined using SetDelayed or
> macro is referenced, it is recomputed in Set or assignment (and in SetDelayed 
> or
> macro when these are computed), and this occurs recursively until all
> identifiers at the "leaves" are resolved with Set or assigned values. The
> SetDelayed or macro defined identifiers have no "values" associated and the
> values are computed on demand. Do you consider this delayed computation lazy
> re-evaluation? [I put "values" in quotation because the word value can have
> different meanings at different levels; at a functional level, the SetDelayed 
> or
> macro defined identifiers of course have associated "values".]

Bill pointed out that this is really "lazy evaluation".

I think lazy evaluation also deserves some thought.  It could be used to
simulate lazy re-evaluation, but again it forces a full recomputation
each time.  Re-evaluation aims to compute as little as possible to
return the worksheet to a consistent state.

The combination of macros/SetDelayed and Eval have always bothered me a
lot.  It is generally possible to have multiple levels of this, so that
to compute an expression requires multiple evals:
eval(eval(expression)).  Some functions (like Plot) do not evaluate
their argument while most others do.

The situation is highly confusing.  I think there may be a smarter way
to do it, implementing lazy re-evaluation, while at the same time hiding
*all* of the SetDelayed/Eval mess from the user.  I find myself in a
situation occasionally: "How many times do I have to evaluate this to
get a number?"  "Do I need to use evalc() or evalm()?"  (evalc and evalm
are Maple's complex and matrix evaluators)

Can anyone think of an example using axiom macros demonstrating a
calculation that cannot be done any other way?  Can we think of a way to
map it onto a different paradigm (lazy re-evaluation maybe?) that can
also arrive at the correct answer?

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

signature.asc
Description: Digital signature