|
36
|
1 Team: Rhope Burn
|
|
|
2 Language: Quiche
|
|
|
3 Members: Michael Pavone, William Morgan
|
|
|
4
|
|
|
5 HOW TO BUILD:
|
|
|
6
|
|
|
7 To build our Lambda-man AI, you first need to build the lmc compiler. lmc is
|
|
|
8 written in a WIP language called Quiche. The steps to get a Quiche toolchain
|
|
|
9 setup are as follows:
|
|
|
10
|
|
|
11 1) Make a local clone of hg repo: http://rhope.retrodev.com/repos/tabletprog
|
|
|
12 2) Make sure the d8 Javascript shell (built from Chrome's v8) is in your path
|
|
|
13 -- see this page for instructions on how to build d8:
|
|
|
14 https://developers.google.com/v8/build
|
|
|
15 3) Install the Boehm GC development package (libgc-dev on Debian derivatives)
|
|
|
16 3) Install gcc if it is not already present
|
|
|
17
|
|
|
18 Once you have the toolchain in place, navigate to the Quiche repo clone in a
|
|
|
19 terminal and execute the following command.
|
|
|
20
|
|
|
21 ./compile PATH/TO/lmc.tp
|
|
|
22
|
|
|
23 If all goes well an executable named lmc will be produced at PATH/TO/lmc. This
|
|
|
24 program takes a .lm file as an argument and produces "GCC" assembly code on
|
|
|
25 stdout.
|
|
|
26
|
|
|
27 ABOUTE QUICHE:
|
|
|
28
|
|
|
29 Quiche (previously called TP) is a language I (Michael Pavone) work on in my
|
|
|
30 spare time. It draws rather heavily from Smalltalk with a smattering of
|
|
|
31 influence from other languages. In theory, it's reason for existence is to be
|
|
|
32 a good target for a structured editor on mobile devices. In practice, I'd
|
|
|
33 probably be better served targeting an existing language, but that's not nearly
|
|
|
34 as much fun.
|
|
|
35
|
|
|
36 The current implementation is a quick and dirty bootstrap compiler written in
|
|
|
37 Javascript that produces C code. A self-hosted compiler is in progress.
|
|
|
38
|
|
|
39 A Quiche program is made up of one or more modules. At runtime, a module is
|
|
|
40 just a plain object. Only one module is allowed per source file. The top level
|
|
|
41 of a Quiche source file is required to either be an object literal or a lambda
|
|
|
42 that returns an object. After all modules used are initialized, execution
|
|
|
43 starts in the main method of the main module. Currently, the names of all
|
|
|
44 available modules occupy the top level of the symbol table; however, this will
|
|
|
45 change in the self-hosted compiler.
|
|
|
46
|
|
|
47 QUICHE SYNTAX:
|
|
|
48
|
|
|
49 To make reading lmc's code a bit easier, here is a quick primer on Quiche's
|
|
|
50 syntax.
|
|
|
51
|
|
|
52 line comment: //
|
|
|
53 block comment: /* */
|
|
|
54 assignment: foo <- bar
|
|
|
55 list literal: [1 2 3 4]
|
|
|
56 array literal: #[1 2 3 4]
|
|
|
57 string literal "foo bar"
|
|
|
58 lambda: :arg {
|
|
|
59 arg + 1
|
|
|
60 }
|
|
|
61 object literal: #{
|
|
|
62 foo <- "blah blah"
|
|
|
63 bar <- :val {
|
|
|
64 foo <- val . " blah"
|
|
|
65 }
|
|
|
66 }
|
|
|
67 method invokation/function application:
|
|
|
68 someval someFunOrMeth
|
|
|
69 someFunOrMeth: someval
|
|
|
70 some: val1 Fun: val2 OrMeth: val3
|
|
|
71 some:Fun:OrMeth: val1 val2 val3
|
|
|
72 operators:
|
|
|
73 +,-,/,* -- basic arithmetic
|
|
|
74 =,!=,>=,<= -- comparison
|
|
|
75 and,or,xor -- bitwise
|
|
|
76 % -- modulus
|
|
|
77 . -- concatenation
|
|
|
78 | -- cons
|
|
|
79
|
|
|
80 ABOUT LMC:
|
|
|
81
|
|
|
82 lmc implements a subset of Quiche for the LamCo General Compute Coprocessor. It
|
|
|
83 uses the parser, ast and symbols modules from the work in progress self-hosted
|
|
|
84 compiler. Object literals are not supported apart from the top-level object
|
|
|
85 that represents the module. That object is used to populate the global
|
|
|
86 environment. Closures are properly supported; however, some elements that are
|
|
|
87 implemented using closures in the normal Quiche compiler (namely if:else and
|
|
|
88 while:do) are instead implemented as special forms that do not introduce a new
|
|
|
89 scope. Array literals are used for producing tuples as the GCC does not really
|
|
|
90 support the former and Quiche does not currently support the latter.
|
|
|
91
|
|
|
92 Tail call optimization is notcurrently implemented; however, while:do is
|
|
|
93 implemented using TSEL so we were able to do without.
|
|
|
94
|
|
|
95 LIGHTNING ROUND SOLUTION:
|
|
|
96
|
|
|
97 Our lightning round solution is relatively simple. Each step, we do a breadth
|
|
|
98 first search for something desirable (pellet, power pellet, fruit or fright
|
|
|
99 mode ghost). Cells occupied by normal mode ghosts and their immediate neighbors
|
|
|
100 are marked as walls to provide simple avoidance behavior.
|
|
|
101
|
|
|
102 We translate the grid to a tree format to provide more efficient lookup. An
|
|
|
103 identically dimensioned tree is used for keeping track of visited nodes for our
|
|
|
104 search.
|
|
|
105
|
|
|
106 This seems to work surprisingly well given how simple it is. I'm a bit
|
|
|
107 concerned about our cycle usage when the nearest "good" thing is far away,
|
|
|
108 hopefully that will not be an issue.
|
|
|
109
|
|
|
110 We noticed that the "undefined" input to main appears to be the ghost code, but
|
|
|
111 we did not have time to take advantage of it for the lightning round.
|
|
|
112
|
|
|
113 The code for this AI is located in dotScanner.lm
|
|
|
114
|
|
|
115 OTHER FILES:
|
|
|
116
|
|
|
117 test.lm - random collection of syntax for exercising parts of the compiler
|
|
|
118 simple.lm - picks each direction in order every 4 turns
|
|
|
119 mike00.lm - test program for developing library functions
|
