From 6131ceeb54b0a590466f07e4f47f236a6f691e65 Mon Sep 17 00:00:00 2001 From: John Clements Date: Wed, 21 Sep 2005 23:06:41 +0000 Subject: [PATCH] added notes svn: r899 --- notes/stepper/DESIGN-NOTES | 39 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/notes/stepper/DESIGN-NOTES b/notes/stepper/DESIGN-NOTES index edcb2cc527..fda6570f93 100644 --- a/notes/stepper/DESIGN-NOTES +++ b/notes/stepper/DESIGN-NOTES @@ -803,3 +803,42 @@ outside in? Feh. 2005-08-02 +************* + +Okay, I've "completed" the google project, but there are still things +to wrap up. Right now I'm working on the highlighting for mutated +bindings, which is inferred from differences in the rendered steps. + +So, for instance, if the left-hand-side has (define a 3), and the +right-hand-side has (define a 4), well then we'd better highlight the +3 on the left and the 4 on the right, because this binding was +mutated. + +Now, this kind of highlighting--reconstructing highlighting from +observed differences, rather than obtaining direct evidence of the +mutation--clearly has some shortcomings. For instance, concurrent +code... well, concurrent code is all messed up to begin with; a +more interesting problem occurs when you have mutations that share +structure. So, what if a is mutated from (list 3 4) to (list 4 5). +Should the whole thing be highlighted? Certainly that's what you'd +get from a a normal reduction semantics. In some sense, though, +highlighting _just_ the 3 and the 4 (and the 4 and the 5) corresponds +to a smaller set of changes that produces the same result. + +Another problem that's coming out is the problem of "intermediate" +completed expressions that arise from partially evaluated letrecs +(and all the things that expand into them). These should also be +scanned for mutation, right? What about the "future" ones? There +are other rendering problems with forward mutation in letrecs which +I haven't tackled, as well. I find myself leaning toward depending +on the "user-source" syntax property. As I've observed before, though, +the syntax properties form a sort of creeping mush; they don't need +to be explicitly expressed as arguments or return values, and errors +of omission in the syntax properties are hard to catch. A lot can +hide in the "syntax?" contract. + +2005-09-21 + +************** + +