--- a/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt	Wed Sep 22 11:58:04 2010 -0400
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_RP.txt	Wed Sep 22 12:12:30 2010 -0400
@@ -1,8 +1,11 @@
 I agree with Ian, maybe using caps is not the best idea. It reminds be of BASIC which I used to do long time ago :). It also makes the code look a bit scary.
 
+JB replies: personally i think it makes the code look more AWESOME but I could
+go either way.  See reply to Ian in plugin_JB_comments_IG.txt
+
 I like the approach and I think it goes close to my earliest proposition and to what I am proposing for the layer committeee ( though we did not have a meeting yet). 
-I would though write it in a more Theano like ( Ian has a example of how that would look). I would also drop the CALL and FLIT constructs, and actually have a 
-decorator ( or something ) that wraps around a function to transform it into a call or flit. I hope that this is only syntactic sugar ( does this change anything
+I would though write it in a more Theano like ( Ian has a example of how that would look). I would also drop the CALL and FILT constructs, and actually have a 
+decorator ( or something ) that wraps around a function to transform it into a call or filt. I hope that this is only syntactic sugar ( does this change anything
 in the actual implementation ?? ) that makes things more natural. What I want to reach is something that looks very much as Theano, just that now you are creating
 the graph of execution steps. Refractoring what you wrote this will look like
 
@@ -11,7 +14,7 @@
 
 train_pca.run()
 
-If you allow a FLIT to also get multiple inputs ( so not just the one) which comes natural in this way of writing you can get to describe a DAG that not only 
+If you allow a FILT to also get multiple inputs ( so not just the one) which comes natural in this way of writing you can get to describe a DAG that not only 
 describes the order of execution but also deals with what takes data from what. I'm sorry for not being there yesturday, from what I remember I have the 
 feeling that for you that is done under the hood and not taken care by this flow control structures. 
 
@@ -50,7 +53,7 @@
 
 
 GPU_transform,gaussian_noise and so on are functions that have been decorated ( or classes if you want) 
-that you would write using FLIT.  Reconstruct for me is a different CONTROL FLOW element. 
+that you would write using FILT.  Reconstruct for me is a different CONTROL FLOW element. 
 In this case I don't use REPEAT or BUFFER_REPEAT or the other very cool control flow elements, but you
 can easily imagine writing something like
 
@@ -58,3 +61,30 @@
 results = spawn(repeat(5000,learner1),repeat(500,learner2))
 
 
+JB replies:
+
+  This reply makes it clearer to me that I was not sensitive enough to the
+  difference between *expressions* and *control-flow statements*.  What you have
+  above is a graph of declarative expressions (if I understand correctly) with
+  certain properties:
+
+    - they have no side effects
+    - they can be re-ordered within dependency constraints
+
+  Contrast this with the CALL statements in my proposal:
+
+    - they work primarily by side effect
+    - they cannot be re-ordered at all
+
+  So the fact that CALL currently works by side effect means that there is
+  almost no graph-manipulation that can be guaranteed not to change the program.
+  This is a reason to make CALL statements *encapsulate* programs constructed
+  using declarative constructs (i.e. Theano functions)
+
+  In other words, in this short term, this feels to me like the reason to *not*
+  mix Theano graph building with this control-flow business.  
+
+  Consequently, I think I will remove the BUFFER_REPEAT construct since that is
+  really an expression masquerading as a control flow statement, and I will
+  remove FILT too.
+