# HG changeset patch
# User James Bergstra <bergstrj@iro.umontreal.ca>
# Date 1285171084 14400
# Node ID 4754661ad6ab3d4ce55894a061905bde4125a81a
# Parent  681b5e7e3b81ea9198537420dbfc68969f4d7049
reply to plugin_JB_comments_IG

diff -r 681b5e7e3b81 -r 4754661ad6ab doc/v2_planning/arch_src/plugin_JB_comments_IG.txt
--- a/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt	Wed Sep 22 10:39:39 2010 -0400
+++ b/doc/v2_planning/arch_src/plugin_JB_comments_IG.txt	Wed Sep 22 11:58:04 2010 -0400
@@ -1,4 +1,18 @@
 -Does everything have to be all caps? I know I will get annoyed with that.
+ - JB replies: I chose caps because 
+
+   a) I wanted to be able to use statements like IF, WHILE, etc. that are
+   reserved words in Python in lower case... but this turned out not to be a
+   large overlap
+
+   b) I wanted to make up for the lack of syntax highlighting of control flow
+   statements in VIM by making the words bigger.
+
+   c) I thought it looked kinda retro-cool.
+
+   Neither of these reasons is really strong, if you or others have strong
+   feelings against caps then no problem.
+
 -Regarding overall program structure:
  Do you think there might be an easier to read/type way of specifying programs than building them out of constructors? This seems like it's going to lead to unwieldy proliferation of parentheses, like in LISP, but since it's an imperative language it's more likely that we'll have lots of different scopes visible at the same time, and it will be hard to tell which section is nested inside which other section if they're all just a bunch of constructor calls fed to each other.
  Right now it just seems to take a few layers of SWITCH and SEQ to end up with an unreadable mess:
@@ -59,3 +73,26 @@
 p.run()
 
 If we design our language to be LL(1) (fairly easy to do) then it's pretty easy to make p check that the calls to it are syntactically correct as they happen.
+
+
+JB replies: 
+
+  What I've proposed so far is a few classes for adding new program-flow
+  constructs to Python, which is I think less ambitious and more desirable than
+  defining a separate language.  For example, the bodies of the CALL objects are
+  all python methods (not implemented in my - i hesitate to all it a -
+  "language") and the program itself is constructed using *python* control flow
+  and *python* methods.  I don't want to have another set of syntax rules, or
+  have to create a macro system, or a pre-processor.  
+  
+  I agree it would be nicer to have a more elegant syntax, but I'd much rather
+  live with a few extra parentheses than require someone to go to the trouble of
+  implementing that luxury.  (And we can tweak the control-flow constructors to
+  minimize the number of brackets & parentheses too).
+
+  Besides, we can always implement that language & compiler later. For now we
+  can just type the extra brackets.
+
+  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?