[IPython-dev] notebook composition UI thoughts

[Hans Meine]

On Wednesday 06 July 2005 18:24, Michael Tobis wrote:
> [...] Of course, when I recalculate the cells, the order of execution
> changes and the second result is the expected 25. There are far more
> confusing results that are similar in concept but much more confusing
> in practice. There is also the fact that the notebook inherits
> context from the entire Mathematica session, including all open
> notebooks, that leads to similar flavors of confusion.

Right. That's an important problem to keep in mind.

> One way to look at the problem with the Mathematica model of notebooks
> is that it conflates the purposes of authoring and presentation. As a
> presentation mechanism, the organizing principle is sequential in the
> file space, but as an interactive execution model, the organizing
> principle is sequential in time.

Good point.

> In practice what I will want if I am developing an interactive
> educational, um, thing (I'm not sure "notebook" is the right name) is
> not one but two Python sessions: [...]

I think in this part you just make an assumption on the solution, which might 
not be the right one.  I argue that when developing an interactive, 
educational thing, you do not necessarily want two sessions, but you want a 
repeatable, understandable log.

> [...] For this to make sense I need a new python session (or at least a
> fresh namespace)  invoked every time I make a change in the
> middle of a document. I need anything after the insertion point that
> changes to be highlighted and flagged, and I need multiple undos.

This goes into the direction I pointed out in one of my user stories: What 
you'd really like to have is not to flag everything behind the point, but 
just anything that depends on what you've changed.  *Ideally*, you'd want 
only those parts to be recalculated that actually depend on the changes.

> In the case of a very long document this will cause quite a lot of
> thrashing around as everything gets recalculated.

Ideally, one could just let a dirty flag be passed down a dependency graph, 
and highlight / gray out dirty cells, which would mean only minimal effort

> Perhaps the user 
> interface needs to permit "molecular" rather than atomic changes
> before enforcing a recalculation. That is, I would insert multiple
> input lines from my live session into various places in the notebook
> document before forcing a recalculation of the document.

Right.  The dirty cells should be recalculated only on demand/manual 
activation.

> Knuth observes that the order in which the reader wants to read the
> code does not necessarily match the order in which the compiler wants
> to process it. The flaws in the Mathematica noteboook model show us
> (among other things) that the order in which an author writes code and
> documentation is not necessarily the same as either of them.

OK, then the minimal, nearly trivial first fix for the problem you initially 
presented would be to store the execution order of cells?!
(This corresponds to "the Leo way" BTW, where one could have a sequence of 
cells that make up a program, and then rearrange clones of all those in a 
presentation branch of the outline (in a different order).)
Note that this does not yet solve the problem that code that initialized 
variables could have been overwritten in the meantime, although the variables 
stay in the environment.

Those are interesting problems, OTOH it's hard to save the user from shooting 
him/herself in the foot - he/she will always need to have some kind of idea 
of what happens behind the UI I guess.

Nice greetings,
  Hans