Mercurial > pylearn
changeset 1226:16919775479c
reply to plugin_JB_comments_IG
| author | James Bergstra <bergstrj@iro.umontreal.ca> |
|---|---|
| date | Wed, 22 Sep 2010 17:17:52 -0400 |
| parents | dbac4bd107d8 |
| children | d9f93923765f |
| files | doc/v2_planning/arch_src/plugin_JB_comments_IG.txt |
| diffstat | 1 files changed, 14 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- 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? +