--- a/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt	Wed Sep 22 13:36:30 2010 -0400
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt	Wed Sep 22 14:02:37 2010 -0400
@@ -103,3 +103,54 @@
   proposal, and I don't know how to do it.  Yes, it seems like it would be hard
   and/or awkward, and I don't even really see the advantage of even trying to do
   it.
+
+RP:
+
+  I think you misunderstood me. I did not propose to mix Theano with the
+  library. I agree that would be awkward. What I had in mind ( which might be
+  just something different from what you are doing) is to use some concepts
+  from how Theano deals with things. 
+  
+  For example right now you added registers. Writing something like:
+
+  CALL( fn, arg1, arg2, arg3, _set= reg('x') )
+
+  means actually  reg('x') = fn (arg1,arg2,arg3)
+
+  You get most of what you want because this control flow elements don't
+  actually get executed until you run the program. That means that you 
+  have a fixed simple graph ( you can't play around with it) that tells
+  how to execute your commands. You can save that graph, and the point in 
+  the graph where you stop so that you can resume latter. You can also 
+  save all registers at that point. 
+
+
+  Why not have that fn instead of being a python function, be some class
+  that implements a method run which does what your call would do. 
+  The init/ or __call__ of that class would do what CALL does in your case.
+  Do you think that would be impossible to implement? Any such function 
+  could either return a set of registers or not. 
+
+  Your other control flow things will be just special such functions. 
+  The only thing that would might look a bit strange would be the sequence
+  in case you need to return things. Maybe I could use the same trick,
+  namely a _set arguemnt to __call__.
+
+  I'm not against your approach, I just think it can be written a bit 
+  differently, which in my opinion is easier to read, understand and so 
+  on. I will have nothing against if we decide to write it exactly how you
+  propose and I'm sure that I will get the hang of it pretty fast.
+
+
+  Bottom line (in my view):
+    - I don't say we should mix Theano with anything
+    - I think writing things such that it looks like applying functions to 
+    object is a more natural way, easy to understand for noobs
+    - Writing a new functions by inheriting a class and implementing a method
+    is also natural
+    - I do not propose to do optimizations or play with the graph ! I do
+      though think that you should be able to : 
+        * replace parts of a subgraph with a different
+        * automatically collect hyper-parameters or parameters if you ever want
+        to
+        * change the value of these somehow