git @ Cat's Eye Technologies Larabee / ffa8622
Convert documentation to Markdown. catseye 10 years ago
2 changed file(s) with 313 addition(s) and 333 deletion(s). Raw diff Collapse all Expand all
0 The Larabee Programming Language
1 ================================
2
3 Introduction
4 ------------
5
6 The Larabee programming language, named after everybody's favourite
7 assistant to the Chief of CONTROL, is not a happy-go-lucky language.
8 Indeed no, it has plumbed the very depths of the bottomless pit of its
9 own soul, only to have its true nature revealed to it too quickly, the
10 utter shock of this *denoument* leaving it scarred and reeling.
11
12 You see, Larabee has borrowed the notion of *branch prediction* from the
13 realm of computer processor architecture, and has chosen to abuse it in
14 one simple but rather nasty way: the interpretation of each branch
15 instruction is not just *optimized* by the history of branches
16 previously taken, it is semantically *determined* in part by the history
17 of branches previously taken. Each branch taken (or not taken)
18 increments (or decrements) a value called the branch prediction register
19 (or BPR.) The BPR begins the program at zero; when the BPR is positive,
20 tests are interpreted in the usual way, but when the BPR is negative,
21 the interpretation changes: the "then" and "else" branches are swapped.
22
23 What's more, to prevent (or rather, to *stymie*) working around this by,
24 say, coding up a lot of branches dependent on constant data to "doctor"
25 the BPR to some extremely (high or) low value, no constant data is
26 allowed in a Larabee program. This has the effect of making programs
27 highly dependent on their input.
28
29 But enough of this insipidly sentimental dada. We must move on to
30 insipidly sentimental dada frought with errors and inconsistencies. Woe!
31
32 Syntax
33 ------
34
35 Larabee programs are notated as S-Expressions, familiar from LISP or
36 Scheme. This is not solely because I am too lazy to write a parser. It
37 is also very fitting for a language which has all of the abstraction and
38 finesse of assembly code *sans* immediate mode.
39
40 Larabee forms are as follows:
41
42 - `(op op expr1 expr2)`
43
44 Evaluate expr1, then evaluate expr2, then perform the operation op
45 on the results. Valid ops are `+`, `-`, `*`, and `/`, with their
46 usual integer meanings, and `>`, `<`, and `=` with their usual
47 comparison meanings, with a result of 0 on false and 1 on true.
48 Division by zero is not defined.
49
50 - `(test cond-expr expr1 expr2)`
51
52 `test` evaluates the cond-expr to get either true (non-zero) or
53 false (zero). What happens next depends on the value of the BPR.
54
55 If the BPR is greater than or equal to 0:
56
57 - If cond-expr evaluated to true, evaluate expr1 and decrement the
58 BPR.
59 - If cond-expr evaluated to false, evaluate expr2 and increment
60 the BPR.
61
62 On the other hand, if the BPR is less than 0:
63
64 - If cond-expr evaluated to true, evaluate expr2 and increment the
65 BPR.
66 - If cond-expr evaluated to false, evaluate expr1 and decrement
67 the BPR.
68
69 `test` is the lynchpin upon which Larabee's entire notableness, if
70 any, rests.
71
72 - `(input)`
73
74 Waits for an integer to arrive on the input channel, and evaluates
75 to that integer.
76
77 - `(output expr)`
78
79 Evaluates expr to an integer value and produces that integer value
80 on the output channel.
81
82 - `(store addr-expr value-expr next-expr)`
83
84 Evaluates addr-expr to obtain an address, and value-expr to obtain a
85 value, then places that value in storage at that address,
86 overwriting whatever happened to be stored at that address
87 previously. After all that is said and done, evaluates to next-expr.
88
89 - `(fetch addr-expr)`
90
91 Evaluates addr-expr to obtain an address, then evaluates to whatever
92 value is in storage at that address. Not defined when the currently
93 running Larabee program has never previously `store`d any value at
94 that address.
95
96 - `(label label expr)`
97
98 Indicates that this expr is labelled label. Serves only as a way to
99 reference a program location from another location (with a `goto`;)
100 when executed directly, has no effect over and above simply
101 evaluating expr.
102
103 - `(goto label)`
104
105 Diverts control to the expression in the leftmost, outermost
106 occurrence of a label named label.
107
108 Discussion
109 ----------
110
111 Ah, the burning question: is Larabee Turing-complete? The burning answer
112 is, I think, a technical and somewhat subtle "no".
113
114 But first we must address our subject's special way of dealing with the
115 world. As you've no doubt noticed, Larabee has "issues" with input.
116 (Somewhat interestingly, this emotional baggage was not a direct design
117 goal; it was an unintended consequence of abusing branch prediction and
118 trying to prevent it from going unabused.) These issues will, it turns
119 out, haunt the language unceasingly, day in and day out, with despair
120 and turmoil forever just around the corner.
121
122 A specific hullabaloo induced by Larabee's obdurately retrograde (not to
123 mention completely stupid) input regime is that it's simply not possible
124 to write a program in Larabee which is independent of its input. This
125 alone may make it fail to be Turing-complete, for surely there are many
126 Turing machine programs which are input-invariant, and these programs
127 Larabee cannot legitimately aspire to one day become, or alas, even
128 emulate.
129
130 For example, input invariance is the underlying idea used in converting
131 the usual proof of the uniform halting problem into a (less obvious)
132 proof of the standard halting problem — you say, for any given input,
133 that we can find a machine that erases whatever input it was given,
134 writes the desired input on its tape, and proceeds to perform a
135 computation that we can't decide will halt or not.
136
137 The idea is also embodied in a traditional quine program, which produces
138 a copy of itself on its output, while talking no input. That is, it
139 doesn't matter what input is given to it (and this is often trivial to
140 prove since the quine is generally witten in the subset of the language
141 which does not contain any input instructions.)
142
143 But Larabee can't do either of these things. There is no Larabee program
144 that can replace its arbitrary input with some fixed, constant choice of
145 input. And while you can write a quine, it will require a certain input
146 to produce itself — there will always be other inputs which make it
147 produce something different.
148
149 "So what!" you say, being of bold philosophical bent, "it's mere
150 mereology. Whether we consider the input to be part of the program or
151 not is simply not relevant. Stop trying to confuse me with details and
152 definitions when I already know perfectly well what you're talking
153 about."
154
155 Fine, let's say that. The customer is always right, after all...
156
157 The problem, Wendy, is that Larabee is *still* not Turing-complete. But
158 there are subtler reasons for this. Needle-fine, almost gossamer
159 reasons. Ephemeral reasons with a substantial bouquet; fruity, with
160 notes of chocolate and creosote. I doubt that I can do them justice in
161 prose. However, it still strikes me as a more promising medium than
162 modern dance, I mean at least nominally anyway.
163
164 The reason is basically that you need to know a lower bound on how many
165 tests and variable accesses a Larabee program will make in advance of
166 running it, so you can supply that many values in the input to ensure
167 that the `test`s in the program go where you want them to go.
168
169 (It should be noted that it was rougly at this point that Pressey
170 reached one of the peaks of his so-called "referential" period, in which
171 he was apt to provide "commentary" on his own work, in the form of
172 interjections or asides, as if from the perspective of a historian from
173 a much later era. Such pretentious interruptions were generally not well
174 received, except perhaps by the occasional loser such as yourself.)
175
176 To illustrate, let's try walking through an attempt to have Larabee make
177 a computation. Factorial, say. In pseudocode, it might look like
178
179 a := input
180 b := 1
181 while a > 0 {
182 b := b * a
183 a := a - 1
184 }
185 print b
186
187 Translating this one step toward Larabee, we find the following misty
188 wreck on our doorstep:
189
190 (begin
191 (store a (input))
192 (store b 1)
193 (label loop
194 (begin
195 (store b (op * b a))
196 (store a (op - a 1))
197 (if (op > a 0)
198 (goto loop) (nop))))
199 (print b))
200
201 Now, we can't use names, so we say that a lives at location 1 and b
202 lives at location 2 and we have
203
204 (begin
205 (store 1 (input))
206 (store 2 1)
207 (label loop
208 (begin
209 (store 2 (op * (fetch 2) (fetch 1)))
210 (store 1 (op - (fetch 1) 1))
211 (if (op > (fetch 1) 0)
212 (goto loop) (nop))))
213 (print (fetch 2)))
214
215 Now, we can't have constants either, so we hold our breath and grope
216 around in the dark to obtain
217
218 (begin
219 (store (input) (input))
220 (store (input) (input))
221 (label loop
222 (begin
223 (store (input) (op * (fetch (input)) (fetch (input))))
224 (store (input) (op - (fetch (input)) (input)))
225 (if (op > (fetch (input)) (input))
226 (goto loop) (nop))))
227 (print (fetch (input))))
228
229 ...with the understanding that the appropriate inputs for this program
230 are ones that have 0, 1, and 2 in the right places. Naturally, sadly,
231 magnificently, other kinds of inputs will produce other, most likely
232 non-factorial programs.
233
234 Lastly, we have to give up hope of ever seeing the familiar shores of
235 our homeland again, bite the bullet and kick the `if` habit:
236
237 (begin
238 (store (input) (input))
239 (store (input) (input))
240 (label loop
241 (begin
242 (store (input) (op * (fetch (input)) (fetch (input))))
243 (store (input) (op - (fetch (input)) (input)))
244 (test (op > (fetch (input)) (input))
245 (goto loop) (nop))))
246 (print (fetch (input))))
247
248 And, oh, actually, we don't have `begin` — nor `nop`, neither. Hooray!
249
250 (store (input) (input)
251 (store (input) (input)
252 (label loop
253 (store (input) (op * (fetch (input)) (fetch (input)))
254 (store (input) (op - (fetch (input)) (input))
255 (test (op > (fetch (input)) (input))
256 (goto loop) (print (fetch (input)))))))))
257
258 Now, if you've been following that, and if you can imagine in the
259 slightest how the input will need to look for any given integer, to
260 produce the correct factorial result on the output — even *assuming* you
261 added a bunch of `test`s somewhere in the program and fed them all the
262 right numbers so that the important `test` turned out the way you wanted
263 — then I needn't go to the extra trouble of a rigourous proof to
264 convince you that Larabee is not Turing-complete.
265
266 If, on the other hand, you decide to be stubborn and you say well that
267 might be a very involved encoding you're forcing on the input but it's
268 just an encoding and every language is going to force *some* encoding on
269 the input so *duh* you haven't shown me anything *really*, I'd have to
270 pull out the dreaded ARGUMENT BY ACKERMANN'S FUNCTION. However, I'd
271 really rather not, as it's late, and I'm tired. Maybe later.
272
273 *(later)* OK, it goes something like this. Ackermann's function — which
274 we know we need at least something that can do better than
275 primitive-recursive, to compute — has a lower-bound complexity on the
276 order of, well, Ackermann's function. (This in itself seems to be one of
277 those mathematical oddities that seems wiggy when you first hear about
278 it, then self-evident after you've thought about it for a few months...
279 and, if you are lucky, no less wiggy.) So anyway, what does that imply
280 about how many items would need to be input to a Larabee program that
281 computes Ackermann's function? And what does *that* imply about what
282 you'd need to obtain that input in the first place? Hmm? Hmm?
283
284 Trivia
285 ------
286
287 There is an implementation of Larabee written in a relatively pure
288 subset of Scheme. I hesitate to call it a reference implementation, but
289 it seems I have no choice in these matters.
290
291 Conclusion
292 ----------
293
294 It has come time to say goodbye to our subject, our illustrious
295 monstrosity, our glorious bottom-feeder, our feel-good cripple of the
296 year. With such a distressing burden to bear, what's a programming
297 language to do? Who could begrudge it seeking comfort in the arms of an
298 understanding mistress, a bottle of bourbon, the Cone of Silence? But
299 even so, saving such wretched constructions from their own
300 self-annihilation, so we may all learn from its example — this is one of
301 the very reasons we run this Home for Wayward Calculi, is it not?
302
303 Indeed.
304
305 This is the place where ordinarily where I would wish you a happy
306 something or other. But I shall graciously decline this time; it is all
307 too clear that there is simply no happiness left.
308
309 -Chris Pressey
310 January 10, 2008
311 Chicago, Illinois
312 RICHARD M. DALEY, MAYOR
+0
-333
doc/larabee.html less more
0 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
1 <!-- encoding: UTF-8 -->
2 <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
5 <title>The Larabee Programming Language</title>
6 <!-- begin html doc dynamic markup -->
7 <script type="text/javascript" src="/contrib/jquery-1.6.4.min.js"></script>
8 <script type="text/javascript" src="/scripts/documentation.js"></script>
9 <!-- end html doc dynamic markup -->
10 </head>
11 <body>
12
13 <h1>The Larabee Programming Language</h1>
14
15 <h2>Introduction</h2>
16
17 <p>The Larabee programming language, named after everybody's favourite
18 assistant to the Chief of CONTROL, is not a happy-go-lucky language.
19 Indeed no, it has plumbed the very depths of the bottomless pit of its own soul,
20 only to have its true nature revealed to it too quickly, the utter shock of this
21 <i>denoument</i> leaving it scarred and reeling.</p>
22
23 <p>You see, Larabee has borrowed the notion of <em>branch prediction</em>
24 from the realm of computer processor architecture, and has chosen to abuse it in
25 one simple but rather nasty way: the interpretation of each branch instruction is not
26 just <em>optimized</em> by the history of branches previously taken, it is
27 semantically <em>determined</em> in part by the history of branches
28 previously taken.
29 Each branch taken (or not taken) increments (or decrements) a value called
30 the branch prediction register (or BPR.) The BPR begins the program at
31 zero; when the BPR is positive, tests are interpreted in the usual way,
32 but when the BPR is negative, the interpretation changes: the
33 "then" and "else" branches are swapped.</p>
34
35 <p>What's more, to prevent (or rather, to <em>stymie</em>) working around
36 this by, say, coding up a lot of branches dependent on constant data to
37 "doctor" the BPR to some extremely (high or) low value, no constant data
38 is allowed in a Larabee program. This has the effect of making programs
39 highly dependent on their input.</p>
40
41 <p>But enough of this insipidly sentimental dada. We must move on to
42 insipidly sentimental dada frought with errors and inconsistencies. Woe!</p>
43
44 <h2>Syntax</h2>
45
46 <p>Larabee programs are notated as S-Expressions, familiar from LISP or
47 Scheme. This is not solely because I am too lazy to write a parser. It is also
48 very fitting for a language which has all of the abstraction and finesse
49 of assembly code <i>sans</i> immediate mode.</p>
50
51 <p>Larabee forms are as follows:</p>
52
53 <ul>
54
55 <li><code>(op <var>op</var> <var>expr1</var> <var>expr2</var>)</code>
56 <p>Evaluate <var>expr1</var>, then evaluate <var>expr2</var>, then perform the operation <var>op</var> on the results.
57 Valid <var>op</var>s are <code>+</code>, <code>-</code>, <code>*</code>,
58 and <code>/</code>, with their usual integer meanings, and
59 <code>&gt;</code>, <code>&lt;</code>, and <code>=</code>
60 with their usual comparison meanings, with a result of 0 on false and 1 on true.
61 Division by zero is not defined.</p>
62 </li>
63
64 <li><code>(test <var>cond-expr</var> <var>expr1</var> <var>expr2</var>)</code>
65
66 <p><code>test</code> evaluates the <var>cond-expr</var> to get either true
67 (non-zero) or false (zero). What happens next depends on the value of the BPR.</p>
68
69 <p>If the BPR is greater than or equal to 0:</p>
70
71 <ul>
72 <li>If <var>cond-expr</var> evaluated to true, evaluate <var>expr1</var> and decrement the BPR.</li>
73 <li>If <var>cond-expr</var> evaluated to false, evaluate <var>expr2</var> and increment the BPR.</li>
74 </ul>
75
76 <p>On the other hand, if the BPR is less than 0:</p>
77
78 <ul>
79 <li>If <var>cond-expr</var> evaluated to true, evaluate <var>expr2</var> and increment the BPR.</li>
80 <li>If <var>cond-expr</var> evaluated to false, evaluate <var>expr1</var> and decrement the BPR.</li>
81 </ul>
82
83 <p><code>test</code> is the lynchpin upon which Larabee's entire
84 notableness, if any, rests.</p>
85
86 </li>
87
88 <li><code>(input)</code>
89 <p>Waits for an integer to arrive on the input channel, and evaluates to that
90 integer.</p>
91 </li>
92
93 <li><code>(output <var>expr</var>)</code>
94 <p>Evaluates <var>expr</var> to an integer value and produces that
95 integer value on the output channel.</p>
96 </li>
97
98 <li><code>(store <var>addr-expr</var> <var>value-expr</var>
99 <var>next-expr</var>)</code>
100 <p>Evaluates <var>addr-expr</var> to obtain an address, and
101 <var>value-expr</var> to obtain a value, then places that value in storage
102 at that address, overwriting whatever happened to be stored at that address
103 previously. After all that is said and done, evaluates to <var>next-expr</var>.</p>
104 </li>
105
106 <li><code>(fetch <var>addr-expr</var>)</code>
107 <p>Evaluates <var>addr-expr</var> to obtain an address, then
108 evaluates to whatever value is in storage at that address. Not defined
109 when the currently running Larabee program has never previously
110 <code>store</code>d any value at that address.</p>
111 </li>
112
113 <li><code>(label <var>label</var> <var>expr</var>)</code>
114 <p>Indicates that this <var>expr</var> is labelled <var>label</var>.
115 Serves only as a way to reference a program location from another
116 location (with a <code>goto</code>;) when executed directly,
117 has no effect over and above simply evaluating <var>expr</var>.</p>
118 </li>
119
120 <li><code>(goto <var>label</var>)</code>
121 <p>Diverts control to the expression in the leftmost, outermost occurrence of
122 a label named <var>label</var>.</p>
123 </li>
124
125 </ul>
126
127 <h2>Discussion</h2>
128
129 <p>Ah, the burning question: is Larabee Turing-complete? The burning answer is,
130 I think, a technical and somewhat subtle "no".</p>
131
132 <p>But first we must address our subject's special way of dealing with the world.
133 As you've no doubt noticed, Larabee has "issues" with input. (Somewhat interestingly,
134 this emotional baggage was not a direct design goal; it was an unintended consequence
135 of abusing branch prediction and trying to prevent it from going unabused.)
136 These issues will, it turns out, haunt the language unceasingly, day in and day out,
137 with despair and turmoil forever just around the corner.</p>
138
139 <p>A specific hullabaloo induced by Larabee's obdurately retrograde
140 (not to mention completely stupid)
141 input regime is that it's simply not possible to write a program in Larabee
142 which is independent of its input. This alone may make it fail to be
143 Turing-complete, for surely there are many Turing machine programs
144 which are input-invariant, and these programs Larabee cannot legitimately
145 aspire to one day become, or alas, even emulate.</p>
146
147 <p>For example, input invariance is the underlying idea used in converting the
148 usual proof of the uniform halting problem into a (less obvious) proof
149 of the standard halting problem — you say, for any given input, that
150 we can find a machine that erases whatever input it was given, writes the
151 desired input on its tape, and proceeds to perform a computation that we can't
152 decide will halt or not.</p>
153
154 <p>The idea is also embodied in a traditional quine program, which produces a
155 copy of itself on its output, while talking no input. That is, it doesn't matter what input
156 is given to it (and this is often trivial to prove since the quine is generally witten in
157 the subset of the language which does not contain any input instructions.)</p>
158
159 <p>But Larabee can't do either of these things. There is no Larabee
160 program that can replace its arbitrary input with some fixed, constant choice of
161 input. And while you can write a quine, it will require a certain input to
162 produce itself — there will always be other inputs which make it
163 produce something different.</p>
164
165 <p>"So what!" you say, being of bold philosophical bent, "it's mere mereology.
166 Whether we consider the input to be part of the program or not is simply not
167 relevant. Stop trying to confuse me with details and definitions when I already know
168 perfectly well what you're talking about."</p>
169
170 <p>Fine, let's say that. The customer is always right, after all...</p>
171
172 <p>The problem, Wendy, is that Larabee is <em>still</em> not Turing-complete.
173 But there are subtler reasons for this. Needle-fine, almost gossamer reasons.
174 Ephemeral reasons with a substantial bouquet; fruity, with notes of chocolate
175 and creosote. I doubt that I can do them justice in prose. However, it still
176 strikes me as a more promising medium than modern dance, I mean at least nominally
177 anyway.</p>
178
179 <p>The reason is basically that you need to know a lower bound on
180 how many tests and variable accesses a Larabee program will make in advance
181 of running it, so you can supply that many values in the input to ensure that
182 the <code>test</code>s in the program go where you want them to go.</p>
183
184 <p>(It should be noted that it was rougly at this point that Pressey reached one of the
185 peaks of his so-called "referential" period, in which he was apt to provide "commentary"
186 on his own work, in the form of interjections or asides, as if from the perspective of a
187 historian from a much later era. Such pretentious interruptions were generally
188 not well received, except perhaps by the occasional loser such as yourself.)</p>
189
190 <p>To illustrate, let's try walking through an attempt to have Larabee make a computation.
191 Factorial, say. In pseudocode, it might look like</p>
192
193 <pre>a := input
194 b := 1
195 while a &gt; 0 {
196 b := b * a
197 a := a - 1
198 }
199 print b</pre>
200
201 <p>Translating this one step toward Larabee, we find the
202 following misty wreck on our doorstep:</p>
203
204 <pre>(begin
205 (store a (input))
206 (store b 1)
207 (label loop
208 (begin
209 (store b (op * b a))
210 (store a (op - a 1))
211 (if (op &gt; a 0)
212 (goto loop) (nop))))
213 (print b))</pre>
214
215 <p>Now, we can't use names, so we say that a lives at
216 location 1 and b lives at location 2 and we have</p>
217
218 <pre>(begin
219 (store 1 (input))
220 (store 2 1)
221 (label loop
222 (begin
223 (store 2 (op * (fetch 2) (fetch 1)))
224 (store 1 (op - (fetch 1) 1))
225 (if (op &gt; (fetch 1) 0)
226 (goto loop) (nop))))
227 (print (fetch 2)))</pre>
228
229 <p>Now, we can't have constants either, so we hold our
230 breath and grope around in the dark to obtain</p>
231
232 <pre>(begin
233 (store (input) (input))
234 (store (input) (input))
235 (label loop
236 (begin
237 (store (input) (op * (fetch (input)) (fetch (input))))
238 (store (input) (op - (fetch (input)) (input)))
239 (if (op &gt; (fetch (input)) (input))
240 (goto loop) (nop))))
241 (print (fetch (input))))</pre>
242
243 <p>...with the understanding that the appropriate inputs for this
244 program are ones that have 0, 1, and 2 in the right places.
245 Naturally, sadly, magnificently, other kinds of inputs will
246 produce other, most likely non-factorial programs.</p>
247
248 <p>Lastly, we have to give up hope of ever seeing the familiar shores of
249 our homeland again, bite the bullet and kick the <code>if</code>
250 habit:</p>
251
252 <pre>(begin
253 (store (input) (input))
254 (store (input) (input))
255 (label loop
256 (begin
257 (store (input) (op * (fetch (input)) (fetch (input))))
258 (store (input) (op - (fetch (input)) (input)))
259 (test (op &gt; (fetch (input)) (input))
260 (goto loop) (nop))))
261 (print (fetch (input))))</pre>
262
263 <p>And, oh, actually, we don't have <code>begin</code> —
264 nor <code>nop</code>, neither. Hooray!</p>
265
266 <pre>(store (input) (input)
267 (store (input) (input)
268 (label loop
269 (store (input) (op * (fetch (input)) (fetch (input)))
270 (store (input) (op - (fetch (input)) (input))
271 (test (op &gt; (fetch (input)) (input))
272 (goto loop) (print (fetch (input)))))))))</pre>
273
274 <p>Now, if you've been following that, and if you can imagine in the
275 slightest how the input will need to look for any given integer, to
276 produce the correct factorial result on the output — even <em>assuming</em>
277 you added a bunch of <code>test</code>s somewhere in the program and
278 fed them all the right numbers so that the important <code>test</code> turned
279 out the way you wanted —
280 then I needn't go to the extra trouble of a rigourous
281 proof to convince you that Larabee is not Turing-complete.</p>
282
283 <p>If, on the other hand, you decide to be stubborn and you say well that might be
284 a very involved encoding you're forcing on the input but it's just an
285 encoding and every language is going to force <em>some</em> encoding on the input
286 so <em>duh</em> you haven't shown me anything <em>really</em>, I'd have to pull out the dreaded
287 ARGUMENT BY ACKERMANN'S FUNCTION. However, I'd really rather not, as it's
288 late, and I'm tired. Maybe later.</p>
289
290 <p><i>(later)</i> OK, it goes something like this. Ackermann's
291 function — which we know we need at least something that can do
292 better than primitive-recursive, to compute — has a lower-bound
293 complexity on the order of, well, Ackermann's function.
294 (This in itself seems to be one of those mathematical oddities that seems
295 wiggy when you first hear about it, then self-evident after you've thought
296 about it for a few months... and, if you are lucky, no less wiggy.)
297 So anyway, what does that imply about how many items would need to be
298 input to a Larabee program that computes Ackermann's function? And what does
299 <em>that</em> imply about what you'd need to obtain that input in the first place?
300 Hmm? Hmm?</p>
301
302 <h2>Trivia</h2>
303
304 <p>There is an implementation of Larabee written in a relatively pure
305 subset of Scheme. I hesitate to call it a reference implementation, but
306 it seems I have no choice in these matters.</p>
307
308 <h2>Conclusion</h2>
309
310 <p>It has come time to say goodbye to our subject, our illustrious monstrosity,
311 our glorious bottom-feeder, our feel-good cripple of the year. With such a
312 distressing burden to bear, what's a programming language to do? Who could
313 begrudge it seeking comfort in the arms of an understanding
314 mistress, a bottle of bourbon, the Cone of Silence? But even so, saving
315 such wretched constructions from their own self-annihilation, so we may all
316 learn from its example — this is one of the very reasons
317 we run this Home for Wayward Calculi, is it not?</p>
318
319 <p>Indeed.</p>
320
321 <p>This is the place where ordinarily where I would wish you a happy something or other.
322 But I shall graciously decline this time; it is all too clear that
323 there is simply no happiness left.</p>
324
325 <p>-Chris Pressey
326 <br />January 10, 2008
327 <br />Chicago, Illinois
328 <br />RICHARD M. DALEY, MAYOR
329 </p>
330
331 </body>
332 </html>