# HG changeset patch
# User Ian Goodfellow
# Date 1285184654 14400
# Node ID f68b857eb11bfcfd1d8b06e7a560904e90090a1b
# Parent  621e03253f0c68f43c3834bd004fdca692b53264
reply to comments on architecture document

diff -r 621e03253f0c -r f68b857eb11b doc/v2_planning/arch_src/plugin_JB_comments_IG.txt
--- a/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt	Wed Sep 22 15:08:39 2010 -0400
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt	Wed Sep 22 15:44:14 2010 -0400
@@ -96,3 +96,17 @@
   Perhaps I don't understand your first example - where do the definitions of A
   and B come from?  Must they be in the same file higher up or something? In
   what language will they be defined?
+
+
+IG replies:
+
+  Doesn't your proposal refer to what is being created as an "imperative
+language"?
+  A, B, etc. are just placeholders for whatever kind of statement you want to
+fill in-- CALL, FILTER, etc. What I wrote wasn't meant to be a real program,
+just an example of how tree-structured programs get mapped into text.
+ The main reason to bring up the issue of a scripting language for assembling
+these constructors is we need to make sure that the set of optional arguments
+to each constructors is such that the scripting language built on top of them
+is LL(1). Fortunately, that is not very hard. When we start converging on the
+final interface I can do the check myself.