|
1213
|
1 -Does everything have to be all caps? I know I will get annoyed with that.
|
|
|
2 -Regarding overall program structure:
|
|
|
3 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.
|
|
|
4 Right now it just seems to take a few layers of SWITCH and SEQ to end up with an unreadable mess:
|
|
|
5 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:
|
|
|
6 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) )
|
|
|
7 This seems like it could quickly turn into a nightmare, trying to count parentheses everywhere. An alternative to make it more parseable is:
|
|
|
8
|
|
|
9 switch1 = SWITCH(var2, val_2_1, D, val_2_2, E)
|
|
|
10 switch2 = SWITCH(var1, val1_1, C, val_1_2, switch1)
|
|
|
11 switch3 = SWITCH(var3, val_3_1, G, val_3_2, H)
|
|
|
12 program = SEQ( A, B, switch2 , F, switch3)
|
|
|
13
|
|
|
14 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.
|
|
|
15
|
|
|
16 It would be much nicer if, since it is a programming language, we could write:
|
|
|
17
|
|
|
18 A
|
|
|
19 B
|
|
|
20 SWITCH var1
|
|
|
21 val1, C
|
|
|
22 val_1_2, SWITCH var2
|
|
|
23 val_2_1, D
|
|
|
24 val_2_2, E
|
|
|
25 F
|
|
|
26 SWITCH var3
|
|
|
27 val_3_1, G
|
|
|
28 val_3_2, H
|
|
|
29
|
|
|
30 I can see a few different ways of accomplishing this, but of couse welcome more proposals:
|
|
|
31
|
|
|
32 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:
|
|
|
33
|
|
|
34 switch.xml contains:
|
|
|
35 <PyLearn>
|
|
|
36 <A />
|
|
|
37 <B />
|
|
|
38 <Switch var="var_1">
|
|
|
39 <Branch val="val_1_1">
|
|
|
40 <C>
|
|
|
41 </Branch>
|
|
|
42 ...
|
|
|
43 </Switch>
|
|
|
44 </Pylearn>
|
|
|
45
|
|
|
46 python pylearn.py switch.xml
|
|
|
47
|
|
|
48 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:
|
|
|
49
|
|
|
50 p = pylearn.program()
|
|
|
51 p(A)
|
|
|
52 p(B)
|
|
|
53 p(SWITCH(var1))
|
|
|
54 p( Branch(val_1_1, C)) #one annoying thing is python wouldn't let us indent things as we please
|
|
|
55 ...
|
|
|
56 p(END_SWITCH)
|
|
|
57 ...
|
|
|
58 p.compile()
|
|
|
59 p.run()
|
|
|
60
|
|
|
61 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.
|
