Mercurial > pylearn
annotate doc/v2_planning/arch_src/plugin_JB_comments_IG.txt @ 1274:9d5905d6d879
hmc - changed updates to member fn from lambda for pickling
author | James Bergstra <bergstrj@iro.umontreal.ca> |
---|---|
date | Wed, 08 Sep 2010 13:17:45 -0400 |
parents | 16919775479c |
children |
rev | line source |
---|---|
1213 | 1 -Does everything have to be all caps? I know I will get annoyed with that. |
1215
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
2 - JB replies: I chose caps because |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
3 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
4 a) I wanted to be able to use statements like IF, WHILE, etc. that are |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
5 reserved words in Python in lower case... but this turned out not to be a |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
6 large overlap |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
7 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
8 b) I wanted to make up for the lack of syntax highlighting of control flow |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
9 statements in VIM by making the words bigger. |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
10 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
11 c) I thought it looked kinda retro-cool. |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
12 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
13 Neither of these reasons is really strong, if you or others have strong |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
14 feelings against caps then no problem. |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
15 |
1213 | 16 -Regarding overall program structure: |
17 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. | |
18 Right now it just seems to take a few layers of SWITCH and SEQ to end up with an unreadable mess: | |
19 I know I'm not getting the syntax exactly matched to you proposal, but just to illustrate what I'm saying, we could have a program that looks like this: | |
20 program = SEQ( A, B, SWITCH(var1, val1_1, C, val_1_2, SWITCH(var2, val_2_1, D, val_2_2, E) ) , F, SWITCH(var3, val_3_1, G, val_3_2, H) ) | |
21 This seems like it could quickly turn into a nightmare, trying to count parentheses everywhere. An alternative to make it more parseable is: | |
22 | |
23 switch1 = SWITCH(var2, val_2_1, D, val_2_2, E) | |
24 switch2 = SWITCH(var1, val1_1, C, val_1_2, switch1) | |
25 switch3 = SWITCH(var3, val_3_1, G, val_3_2, H) | |
26 program = SEQ( A, B, switch2 , F, switch3) | |
27 | |
28 This is a lot more manageable but now the parts are out of order, so the cognitive load required to debug and understand it doesn't scale well with program size. | |
29 | |
30 It would be much nicer if, since it is a programming language, we could write: | |
31 | |
32 A | |
33 B | |
34 SWITCH var1 | |
35 val1, C | |
36 val_1_2, SWITCH var2 | |
37 val_2_1, D | |
38 val_2_2, E | |
39 F | |
40 SWITCH var3 | |
41 val_3_1, G | |
42 val_3_2, H | |
43 | |
44 I can see a few different ways of accomplishing this, but of couse welcome more proposals: | |
45 | |
46 1) Make a scripting language, so we pass a file into our library. We could base it on XML, maybe, if we didn't want to spend too much time making our own parser: | |
47 | |
48 switch.xml contains: | |
49 <PyLearn> | |
50 <A /> | |
51 <B /> | |
52 <Switch var="var_1"> | |
53 <Branch val="val_1_1"> | |
54 <C> | |
55 </Branch> | |
56 ... | |
57 </Switch> | |
58 </Pylearn> | |
59 | |
60 python pylearn.py switch.xml | |
61 | |
62 2) We could make a global program compiler or have program objects that have an idea of the current scope, that you just add things to: | |
63 | |
64 p = pylearn.program() | |
65 p(A) | |
66 p(B) | |
67 p(SWITCH(var1)) | |
68 p( Branch(val_1_1, C)) #one annoying thing is python wouldn't let us indent things as we please | |
69 ... | |
70 p(END_SWITCH) | |
71 ... | |
72 p.compile() | |
73 p.run() | |
74 | |
75 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. | |
1215
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
76 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
77 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
78 JB replies: |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
79 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
80 What I've proposed so far is a few classes for adding new program-flow |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
81 constructs to Python, which is I think less ambitious and more desirable than |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
82 defining a separate language. For example, the bodies of the CALL objects are |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
83 all python methods (not implemented in my - i hesitate to all it a - |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
84 "language") and the program itself is constructed using *python* control flow |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
85 and *python* methods. I don't want to have another set of syntax rules, or |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
86 have to create a macro system, or a pre-processor. |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
87 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
88 I agree it would be nicer to have a more elegant syntax, but I'd much rather |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
89 live with a few extra parentheses than require someone to go to the trouble of |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
90 implementing that luxury. (And we can tweak the control-flow constructors to |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
91 minimize the number of brackets & parentheses too). |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
92 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
93 Besides, we can always implement that language & compiler later. For now we |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
94 can just type the extra brackets. |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
95 |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
96 Perhaps I don't understand your first example - where do the definitions of A |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
97 and B come from? Must they be in the same file higher up or something? In |
4754661ad6ab
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1213
diff
changeset
|
98 what language will they be defined? |
1224 | 99 |
100 | |
101 IG replies: | |
102 | |
103 Doesn't your proposal refer to what is being created as an "imperative | |
104 language"? | |
105 A, B, etc. are just placeholders for whatever kind of statement you want to | |
106 fill in-- CALL, FILTER, etc. What I wrote wasn't meant to be a real program, | |
107 just an example of how tree-structured programs get mapped into text. | |
108 The main reason to bring up the issue of a scripting language for assembling | |
109 these constructors is we need to make sure that the set of optional arguments | |
110 to each constructors is such that the scripting language built on top of them | |
111 is LL(1). Fortunately, that is not very hard. When we start converging on the | |
112 final interface I can do the check myself. | |
1226
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
113 |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
114 JB replies: |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
115 |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
116 I don't know if this is standard - but I think of a language as being ... |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
117 maybe... "the set of all syntactic elements which which you make a program", |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
118 and by that criterion I am not proposing a complete language. I attempt a |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
119 definition because these control-flow programs are expressed in ELEMENTs that |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
120 eventually bottom out at CALL(X, ...) where X is *not* defined in the |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
121 control-flow language. X is a Python function that typically (and maybe |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
122 necessarily - I'm not sure) knows nothing about the control-flow language that |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
123 is calling it. So with this view in mind, I can't understand why or how it |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
124 would make sense to define the control flow in a new language, or in XML or |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
125 something. After all, how are you going to tell it what to CALL? |
16919775479c
reply to plugin_JB_comments_IG
James Bergstra <bergstrj@iro.umontreal.ca>
parents:
1224
diff
changeset
|
126 |