notes and some apply-all work

1 files changed, 37 insertions, 0 deletions

diff --git a/final_project/work/description b/final_project/work/description
index 64b6574..8768e08 100644
--- a/final_project/work/description
+++ b/final_project/work/description
@@ -24,3 +24,40 @@ Related problems (which could be covered by this work?):
     chaining procedures (eg if f maps A->B and g maps B->C, then gof maps
         A->C which might be what we want
     some kind 
+
+
+----------------
+
+To try and/or think about:
+
+* GUI
+* image processing
+* memoization
+* graph-search predicate satisfaction (keep reiterating until predicate sat.)
+* randomized testing
+* introduction of constants as 0-arity generics?
+* generic predicates
+* find and play with other existing generic dispatch systems (SFRIs? xml?)
+
+-----------------
+GUI Spec/vision
+
+A basic GUI would take a single object and display the named operators which
+could act on it as a list with a button for each; clicking the button would
+evaluate that operator and pop up a new window with the text/pp result.
+
+One generalization would be to have the popup result be a list of named 
+operators which could act on that object.
+
+Another generalization would be to allow multiple objects and show their 
+possible combinations for each operator (maybe with a pull down menu?)
+
+Another generalization would be to show higher-arity operators with a text box
+that the user could enter in values for. This could be done even without any
+initial object! Just show the possibilities.
+
+The search for operators could be filtered some how so only interesting
+operators are displayed; it could also be done as a continuation so that the
+first 10 would be displayed, then there would be a button to view the next 10
+operators (eg, turn the search problem into a stream).
+