# HG changeset patch # User James Bergstra # Date 1285190272 14400 # Node ID 16919775479c5f9c09f4587a226237d2c505f949 # Parent dbac4bd107d87aa0d92702a6ad5828fd889f8457 reply to plugin_JB_comments_IG diff -r dbac4bd107d8 -r 16919775479c doc/v2_planning/arch_src/plugin_JB_comments_IG.txt --- a/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt Wed Sep 22 17:04:39 2010 -0400 +++ b/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt Wed Sep 22 17:17:52 2010 -0400 @@ -110,3 +110,17 @@ 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. + +JB replies: + + I don't know if this is standard - but I think of a language as being ... + maybe... "the set of all syntactic elements which which you make a program", + and by that criterion I am not proposing a complete language. I attempt a + definition because these control-flow programs are expressed in ELEMENTs that + eventually bottom out at CALL(X, ...) where X is *not* defined in the + control-flow language. X is a Python function that typically (and maybe + necessarily - I'm not sure) knows nothing about the control-flow language that + is calling it. So with this view in mind, I can't understand why or how it + would make sense to define the control flow in a new language, or in XML or + something. After all, how are you going to tell it what to CALL? +