git @ Cat's Eye Technologies Sally / 674610c
Documentation updates (Markdown formatting, license.) Cat's Eye Technologies 10 years ago
5 changed file(s) with 154 addition(s) and 389 deletion(s). Raw diff Collapse all Expand all
0 The source code files for Sally are made available under the following
1 BSD-style license:
2
3
4 Copyright (c)2000-2011 Chris Pressey, Cat's Eye Technologies.
5 All rights reserved.
6
7 Redistribution and use in source and binary forms, with or without
8 modification, are permitted provided that the following conditions
9 are met:
10
11 1. Redistributions of source code must retain the above copyright
12 notices, this list of conditions and the following disclaimer.
13 2. Redistributions in binary form must reproduce the above copyright
14 notices, this list of conditions, and the following disclaimer in
15 the documentation and/or other materials provided with the
16 distribution.
17 3. Neither the names of the copyright holders nor the names of their
18 contributors may be used to endorse or promote products derived
19 from this software without specific prior written permission.
20
21 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
22 ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
23 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
24 FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
25 COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
26 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
27 BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
28 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
29 CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
30 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
31 ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
32 POSSIBILITY OF SUCH DAMAGE.
+0
-18
doc/CHANGELOG less more
0 Change Log for Sally
1 --------------------
2
3 2000.0226
4
5 Original release.
6
7 2003.1104
8
9 Added GNU Makefile.
10 Added bin/ and lib/ subdirectories.
11 Split sally.c into sally.c and runtime.c.
12 Added libsally library.
13
14 2010.0428
15
16 Made compilable with -ansi -pedantic.
17 Made documentation conform to XHTML 1.0 Strict.
0 Sally
1 A Strongly-Typed Language
2 -------------------------
3 v2000.02.26 (c)2000 Cat's-Eye Technologies. All rights reserved.
0 Sally, a Strongly-Typed Language
1 ================================
2
3 Version 1.0, Revision 2011.1231.
44
55 What is Sally?
66 --------------
77
88 Sally is basically FORTH, except:
99
10 - All functions are declared with fixed range and domain types
11 - Strong type checking is applied to arguments and results
12 - User-defined types can be introduced into the checking scheme
13 - Forward, instead of reverse, Polish notation is used
14
15 Sally is also an exercise in the reduction of excise (redundant,
10 - All functions are declared with fixed range and domain types;
11 - Strong type checking is applied to arguments and results;
12 - User-defined types can be introduced into the checking scheme; and
13 - Forward, instead of reverse, Polish notation is used.
14
15 Sally is also an exercise in the reduction of _excise_ (redundant,
1616 extraneous, or sugary syntax).
1717
1818 For example, there is, unlike FORTH, no special symbol to indicate
3434 Each declaration consists of the name and type of a new function
3535 followed by a series of function applications and primitives.
3636
37 The domain types are listed before the function name, the range
38 types, after. For example, a function called foo which maps an
37 The domain types are listed before the function name; the range
38 types, after. For example, a function called `foo` which maps an
3939 integer and a character to an integer, would be notated as
4040
41 int char foo int ...
42
43 The '...' represents the function applications which compose the
41 int char foo int ...
42
43 The '...' represents the function applications which comprise the
4444 body of the function.
4545
4646 The syntax of each application is dictated by the types given in
4747 the function's definition. For example, a correct syntax for
48 applying the 'foo' function above might be
49
50 foo 42 'X
48 applying the `foo` function above might be
49
50 foo 42 'X
5151
5252 (Note the lack of a need for parentheses.) This application of
53 foo would be appropriate anywhere a previous application requires
53 `foo` would be appropriate anywhere a previous application requires
5454 an integer argument, or where a definition requires an integer
5555 result.
5656
5757 Functions can accept multiple arguments and return multiple results.
5858 A function which returns multiple results can pass those results as
5959 a 'chunk' to the previous function application. For example, the
60 following would return the double of the given argument '$1':
61
62 add dup $1
60 following would return the double of the given argument `$1`:
61
62 add dup $1
6363
6464 And this would probably appear in a function definition like so:
6565
66 int double int add dup $1
67
68 The type 'void' indicates lack of any arguments or results. When
66 int double int add dup $1
67
68 The type `void` indicates lack of any arguments or results. When
6969 it indicates the lack of arguments, it must be specified explicitly
7070 (to indicate to the parser that the previous definition has ended.)
7171 When used to indicate the lack of results, it can be implicitly
7373 name.
7474
7575 EXERCISE: See if you can find a way to change the parser so that
76 'void' is always implicit, even when it's used to indicate the
76 `void` is always implicit, even when it's used to indicate the
7777 lack of arguments to a function. Be prepared to deal with a token
7878 which is an undeclared symbol in a mature way.
7979
8282
8383 A function can be passed to another function. In order for a
8484 function to be defined which accepts a function passed to it, a
85 prototype of the type of function to be passed must be defined.
85 _prototype_ of the type of function to be passed must be defined.
8686 This prototype is then preceded in the type declaration by the
87 'like' operator.
87 `like` operator.
8888
8989 For example, say we want a function which accepts an integer
9090 and a function which maps an integer to another integer, and
9191 returns an integer. To do this, first we establish the prototype
9292 function which is included in the arguments to the other function:
9393
94 int map int proto
94 int map int proto
9595
9696 (This kind of definition, a "proto", also functions like a "forward"
9797 declaration in Pascal or an "extern" declaration in C.)
9898
99 We then use the 'like' operator in specifying the definition of the
99 We then use the `like` operator in specifying the definition of the
100100 other function:
101101
102 int like map other int ...
103
104 The function 'other' now takes an integer and a function 'like map'
102 int like map other int ...
103
104 The function `other` now takes an integer and a function 'like map'
105105 (that is, a function which has the same domain and range types as
106 the function called 'map', even if the body of 'map' is not actually
106 the function called `map`, even if the body of `map` is not actually
107107 defined) and returns an integer.
108108
109109 Even so, how does an application pass a function to another function?
110110 You can't just name the function, because that indicates that you want
111111 to apply it and use the return value. You must instead "reference" or
112 "escape" the function by preceding it with "the". So to apply the
113 'other' function above to a function such as 'negate', one would write
114
115 other 5 the negate
116
117 Assuming 'negate' is declared with the same range and domain types as
118 'map', this should pass the function 'negate' without trying to apply
119 it (presumably leaving that up to the 'other' function).
112 "escape" the function by preceding it with `the`. So to apply the
113 `other` function above to a function such as `negate`, one would write
114
115 other 5 the negate
116
117 Assuming `negate` is declared with the same range and domain types as
118 `map`, this should pass the function `negate` without trying to apply
119 it (presumably leaving that up to the `other` function).
120120
121121 Speaking of which, there is one last issue to cover. Once a function
122 like 'other' has a reference to a function like 'map' passed to it,
123 how does 'other' use the passed function?
124
125 The answer is the "do" keyword. "do" is followed by the number of
122 like `other` has a reference to a function like `map` passed to it,
123 how does `other` use the passed function?
124
125 The answer is the `do` keyword. `do` is followed by the number of
126126 an argument. It is not unlike $1, but it does not simply evaluate to
127127 the argument, it actually calls it. When this is the case, the
128128 argument better be a function (all that strong typing stuff applies.)
129129
130 EXERCISE: See if you can extend the "the" operator to provide
130 EXERCISE: See if you can extend the `the` operator to provide
131131 lambda functions. Use the following as a syntax guideline for how
132132 one would specify a lambda function:
133133
134 other 5 the int -> int + $1 7
134 other 5 the int -> int + $1 7
135135
136136 Remember, there's no special "End Function Definition" symbol!
137137
138 EXERCISE: Extend "do" to handle "the" functions directly. Example:
139
140 do the monkey
141
142 EXERCISE: Finally, extend "like" to likewise handle "the" functions
138 EXERCISE: Extend `do` to handle `the` functions directly. Example:
139
140 do the monkey
141
142 EXERCISE: Finally, extend `like` to likewise handle `the` functions
143143 directly. Example:
144144
145 int like the int -> int proto other int ...
145 int like the int -> int proto other int ...
146146
147147 Type Checking and Casting
148148 -------------------------
149149
150150 A named type can defined in Sally by defining it like you would define
151151 a function, but with no range type, and with no definition, instead the
152 token 'type', as in:
153
154 int semaphore type
152 token `type`, as in:
153
154 int semaphore type
155155
156156 In Sally, two types are equivalent if:
157
157158 - Both are named and their names are the same; or
158159 - Neither is named and they are structurally equivalent.
159160
160161 (By named, I of course mean, named by the user, not intrinsic to the
161 language. Even though 'int' is technically a name, it's unnamed for
162 language. Even though `int` is technically a name, it's unnamed for
162163 our purposes here.)
163164
164165 Values can be cast from one type to another. This is invaluable for
165166 any structured data access in Sally.
166167
167168 No conversions are done during type casting. Types can only be
168 cast to other types of the same size (number of elements - you can
169 cast 'char' to 'int' but not to 'int int' or 'void'.)
170
171 Typecasts are performed with the "as" operator, as in
172
173 as char 7
169 cast to other types of the same size (number of elements -- you can
170 cast `char` to `int` but not to `int int` or `void`.)
171
172 Typecasts are performed with the `as` operator, as in
173
174 as char 7
174175
175176 to represent a bell.
176177
177178 EXERCISE: Implement type variables, so that one could define
178179 functions like
179180
180 `1 `2 swap `2 `1 $2 $1
181
182 Which would be applicable no matter what types were passed to and
183 received from 'swap', as long as the types were consistent (all
184 `1's are the same type and all `2's are the same type for any
185 given application of 'swap'.)
181 `1 `2 swap `2 `1 $2 $1
182
183 ...which would be applicable no matter what types were passed to and
184 received from `swap`, as long as the types were consistent (all
185 `` `1 ``'s are the same type and all `` `2 ``'s are the same type, for any
186 given application of `swap`.)
186187
187188 There are several ways one may want to attempt this. One is by
188 using the process of 'unification' to make sure all type variables
189 using the process of _unification_ to make sure all type variables
189190 are used consistently. Adding this to Sally may be excessively
190191 tricky because of the way it does type checking. With a stack of
191192 types, there may be a more efficient algorithm for replacing type
192193 variables with instances, and subsequently checking them for
193194 consistency.
194195
195 Libraries, Side Effects, and main
196 ---------------------------------
196 Libraries, Side Effects, and `main`
197 -----------------------------------
197198
198199 Libraries can be included before the first function definition in a
199200 program. There is no special "include" token, the library is simply
200 named, and if a file named that (plus the extension .sal) is located,
201 named, and if a file named that (plus the extension `.sal`) is located,
201202 it is (virtually) inserted into that point in the program.
202203
203204 For example, many of the sample programs begin with the token
204 'stdlib'. This loads the file stdlib.sal into that point in the
205 `stdlib`. This loads the file `stdlib.sal` into that point in the
205206 program, introducing a handful of function prototypes.
206207
207208 Libraries are also how Sally deals with side effects. The philosophy
209210 paradigm by introducing side effects, they may do so, but they will be
210211 made clearly aware of the fact.
211212
212 Having said that, Sally can only perform side effect communications
213 by including the library called 'sidefxio' - thus reminding the
213 Having said that, Sally can only perform side-effect communications
214 by including the library called `sidefxio` -- thus reminding the
214215 programmer that there are side effect communications at work in the
215216 following program.
216217
217218 Without including this library Sally is limited to batch
218219 communications.
219220
220 In both schemes, the function called 'main' is the function which is
221 applied when the entire program is run. 'main' may have any number
221 In both schemes, the function called `main` is the function which is
222 applied when the entire program is run. `main` may have any number
222223 of arguments and any number of return values, although they may only
223 be of "int" type. For each argument, a value is required as a
224 be of `int` type. For each argument, a value is required as a
224225 command-line argument when the program is run; for each result, the
225226 resultant value is displayed at the end of the program.
226227
228229 does not introduce any side effects in any way, and is capable of
229230 communicating any Turing-solvable problem, so it has some things
230231 going for it. To get around the limitations, however, you have to
231 resort to side effect I/O, where you can use the 'print' and
232 'input' functions to report and obtain information from the user
232 resort to side effect I/O, where you can use the `print` and
233 `input` functions to report and obtain information from the user
233234 while the program is running.
234235
235 EXERCISE: Loosen the constraints on the type of the 'main'
236 function - allow arguments and return values of type 'char'.
236 EXERCISE: Loosen the constraints on the type of the `main`
237 function - allow arguments and return values of type `char`.
237238
238239 EBNF Grammar
239240 ------------
240241
241 Program ::= {Definition}.
242 Definition ::= {Library} {Type} Name {Type}
243 ("type" | "proto" | {Application}).
244 Type ::= "int" | "char" | "like" Name | Name.
245 Application ::= Primitive
246 | "$" Number
247 | (Name | "do" Number) {Instr}
248 | "as" {Type} Instr
249 | "if" Instr Instr Instr
250 | "the" Name.
251 Primitive ::= <<an integer notated in decimal like 123>>
252 | <<a character preceded by a single quote like 'A>>.
242 Program ::= {Definition}.
243 Definition ::= {Library} {Type} Name {Type}
244 ("type" | "proto" | {Application}).
245 Type ::= "int" | "char" | "like" Name | Name.
246 Application ::= Primitive
247 | "$" Number
248 | (Name | "do" Number) {Instr}
249 | "as" {Type} Instr
250 | "if" Instr Instr Instr
251 | "the" Name.
252 Primitive ::= <<an integer notated in decimal like 123>>
253 | <<a character preceded by a single quote like 'A>>.
254
255 Change Log
256 ----------
257
258 2000.0226
259
260 - Original release.
261
262 2003.1104
263
264 - Added GNU Makefile.
265 - Added `bin/` and `lib/` subdirectories.
266 - Split `sally.c` into `sally.c` and `runtime.c`.
267 - Added `libsally` library.
268
269 2010.0428
270
271 - Made compilable with `-ansi -pedantic`.
272 - Made documentation conform to XHTML 1.0 Strict.
273
274 2011.1231
275
276 - Converted language document into Markdown format.
277 - Merged change log into main document.
+0
-275
doc/sally.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 <html xmlns="http://www.w3.org/1999/xhtml" lang="en">
2 <head>
3 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
4 <title>The Sally Programming Language</title>
5 </head>
6 <body>
7
8 <h1>Sally</h1>
9
10 <p>Version 1.0, Revision 2010.0428. &copy;2000-2010 Cat's Eye Technologies.</p>
11
12 <h2>What is Sally?</h2>
13
14 <p>Sally is basically FORTH, except:</p>
15
16 <ul>
17 <li>All functions are declared with fixed range and domain types;</li>
18 <li>Strong type checking is applied to arguments and results;</li>
19 <li>User-defined types can be introduced into the checking scheme;</li>
20 <li>Forward, instead of reverse, Polish notation is used.</li>
21 </ul>
22
23 <p>Sally is also an exercise in the reduction of excise (redundant,
24 extraneous, or sugary syntax).</p>
25
26 <p>For example, there is, unlike FORTH, no special symbol to indicate
27 the end of a function definition. (A new definition starts whenever
28 the previous one ends.)</p>
29
30 <p>The ANSI C source code for the compiler is very small, less than
31 16K in total. The compiler translates Sally programs to ANSI C.</p>
32
33 <p>Just to be silly I've scattered exercises for the reader around the
34 documentation. I don't actually expect anyone to try any of them,
35 but they kind of indicate what I'd like to see in a "Sally++" if
36 there ever was such a beast.</p>
37
38 <h3>Syntax</h3>
39
40 <p>A Sally program consists of a series of function declarations.
41 Each declaration consists of the name and type of a new function
42 followed by a series of function applications and primitives.</p>
43
44 <p>The domain types are listed before the function name, the range
45 types, after. For example, a function called <code>foo</code> which maps an
46 integer and a character to an integer, would be notated as</p>
47
48 <pre> int char foo int ...
49 </pre>
50
51 <p>The <code>...</code> represents the function applications which comprise the
52 body of the function.</p>
53
54 <p>The syntax of each application is dictated by the types given in
55 the function's definition. For example, a correct syntax for
56 applying the <code>foo</code> function above might be</p>
57
58 <pre> foo 42 'X
59 </pre>
60
61 <p>(Note the lack of a need for parentheses.) This application of
62 foo would be appropriate anywhere a previous application requires
63 an integer argument, or where a definition requires an integer
64 result.</p>
65
66 <p>Functions can accept multiple arguments and return multiple results.
67 A function which returns multiple results can pass those results as
68 a 'chunk' to the previous function application. For example, the
69 following would return the double of the given argument <code>$1</code>:</p>
70
71 <pre> add dup $1
72 </pre>
73
74 <p>And this would probably appear in a function definition like so:</p>
75
76 <pre> int double int add dup $1
77 </pre>
78
79 <p>The type <code>void</code> indicates lack of any arguments or results. When
80 it indicates the lack of arguments, it must be specified explicitly
81 (to indicate to the parser that the previous definition has ended.)
82 When used to indicate the lack of results, it can be
83 inferred by the fact that there are no types following the function
84 name.</p>
85
86 <p>EXERCISE: See if you can find a way to change the parser so that
87 <code>void</code> is always implicit, even when it's used to indicate the
88 lack of arguments to a function. Be prepared to deal with a token
89 which is an undeclared symbol in a mature way.</p>
90
91 <h3>Functions which Accept and Return Functions</h3>
92
93 <p>A function can be passed to another function. In order for a
94 function to be defined which accepts a function passed to it, a
95 prototype of the type of function to be passed must be defined.
96 This prototype is then preceded in the type declaration by the
97 <code>like</code> operator.</p>
98
99 <p>For example, say we want a function which accepts an integer
100 and a function which maps an integer to another integer, and
101 returns an integer. To do this, first we establish the prototype
102 function which is included in the arguments to the other function:</p>
103
104 <pre> int map int proto
105 </pre>
106
107 <p>(This kind of definition, a "proto", also functions like a "forward"
108 declaration in Pascal or an "extern" declaration in C.)</p>
109
110 <p>We then use the <code>like</code> operator in specifying the definition of the
111 other function:</p>
112
113 <pre> int like map other int ...
114 </pre>
115
116 <p>The function <code>other</code> now takes an integer and a function 'like map'
117 (that is, a function which has the same domain and range types as
118 the function called <code>map</code>, even if the body of <code>map</code> is not actually
119 defined) and returns an integer.</p>
120
121 <p>Even so, how does an application pass a function to another function?
122 You can't just name the function, because that indicates that you want
123 to apply it and use the return value. You must instead "reference" or
124 "escape" the function by preceding it with <code>the</code>. So to apply the
125 <code>other</code> function above to a function such as <code>negate</code>, one would write</p>
126
127 <pre> other 5 the negate
128 </pre>
129
130 <p>Assuming <code>negate</code> is declared with the same range and domain types as
131 <code>map</code>, this should pass the function <code>negate</code> without trying to apply
132 it (presumably leaving that up to the <code>other</code> function).</p>
133
134 <p>Speaking of which, there is one last issue to cover. Once a function
135 like <code>other</code> has a reference to a function like <code>map</code> passed to it,
136 how does <code>other</code> use the passed function?</p>
137
138 <p>The answer is the <code>do</code> keyword. <code>do</code> is followed by the number of
139 an argument. It is not unlike <code>$1</code>, but it does not simply evaluate to
140 the argument, it actually calls it. When this is the case, the
141 argument better be a function (all that strong typing stuff applies.)</p>
142
143 <p>EXERCISE: See if you can extend the <code>the</code> operator to provide
144 lambda functions. Use the following as a syntax guideline for how
145 one would specify a lambda function:</p>
146
147 <pre> other 5 the int -&gt; int + $1 7
148 </pre>
149
150 <p>Remember, there's no special "End Function Definition" symbol!</p>
151
152 <p>EXERCISE: Extend <code>do</code> to handle <code>the</code> functions directly. Example:</p>
153
154 <pre> do the monkey
155 </pre>
156
157 <p>EXERCISE: Finally, extend <code>like</code> to likewise handle <code>the</code> functions
158 directly. Example:</p>
159
160 <pre> int like the int -&gt; int proto other int ...
161 </pre>
162
163 <h3>Type Checking and Casting</h3>
164
165 <p>A named type can defined in Sally by defining it like you would define
166 a function, but with no range type, and with no definition, instead the
167 token <code>type</code>, as in:</p>
168
169 <pre> int semaphore type
170 </pre>
171
172 <p>In Sally, two types are equivalent if:</p>
173 <ul>
174 <li>Both are named and their names are the same; or</li>
175 <li>Neither is named and they are structurally equivalent.</li>
176 </ul>
177
178 <p>(By named, I of course mean, named by the user, not intrinsic to the
179 language. Even though <code>int</code> is technically a name, it's unnamed for
180 our purposes here.)</p>
181
182 <p>Values can be cast from one type to another. This is invaluable for
183 any structured data access in Sally.</p>
184
185 <p>No conversions are done during type casting. Types can only be
186 cast to other types of the same size (number of elements - you can
187 cast <code>char</code> to <code>int</code> but not to <code>int int</code> or <code>void</code>.)</p>
188
189 <p>Typecasts are performed with the <code>as</code> operator, as in</p>
190
191 <pre> as char 7
192 </pre>
193
194 <p>to represent a bell.</p>
195
196 <p>EXERCISE: Implement type variables, so that one could define
197 functions like</p>
198
199 <pre> `1 `2 swap `2 `1 $2 $1
200 </pre>
201
202 <p>Which would be applicable no matter what types were passed to and
203 received from <code>swap</code>, as long as the types were consistent (all
204 <code>`1</code>'s are the same type and all <code>`2</code>'s are the same type for any
205 given application of <code>swap</code>.)</p>
206
207 <p>There are several ways one may want to attempt this. One is by
208 using the process of <i>unification</i> to make sure all type variables
209 are used consistently. Adding this to Sally may be excessively
210 tricky because of the way it does type checking. With a stack of
211 types, there may be a more efficient algorithm for replacing type
212 variables with instances, and subsequently checking them for
213 consistency.</p>
214
215 <h3>Libraries, Side Effects, and <code>main</code></h3>
216
217 <p>Libraries can be included before the first function definition in a
218 program. There is no special "include" token, the library is simply
219 named, and if a file named that (plus the extension <code>.sal</code>) is located,
220 it is (virtually) inserted into that point in the program.</p>
221
222 <p>For example, many of the sample programs begin with the token
223 <code>stdlib</code>. This loads the file stdlib.sal into that point in the
224 program, introducing a handful of function prototypes.</p>
225
226 <p>Libraries are also how Sally deals with side effects. The philosophy
227 is that if the programmer wants to disturb the purity of the functional
228 paradigm by introducing side effects, they may do so, but they will be
229 made clearly aware of the fact.</p>
230
231 <p>Having said that, Sally can only perform side effect communications
232 by including the library called <code>sidefxio</code> - thus reminding the
233 programmer that there are side effect communications at work in the
234 following program.</p>
235
236 <p>Without including this library Sally is limited to batch
237 communications.</p>
238
239 <p>In both schemes, the function called <code>main</code> is the function which is
240 applied when the entire program is run. <code>main</code> may have any number
241 of arguments and any number of return values, although they may only
242 be of <code>int</code> type. For each argument, a value is required as a
243 command-line argument when the program is run; for each result, the
244 resultant value is displayed at the end of the program.</p>
245
246 <p>This little communications scheme is minimal, and limited, but it
247 does not introduce any side effects in any way, and is capable of
248 communicating any Turing-solvable problem, so it has some things
249 going for it. To get around the limitations, however, you have to
250 resort to side effect I/O, where you can use the 'print' and
251 'input' functions to report and obtain information from the user
252 while the program is running.</p>
253
254 <p>EXERCISE: Loosen the constraints on the type of the <code>main</code>
255 function - allow arguments and return values of type <code>char</code>.</p>
256
257 <h3>EBNF Grammar</h3>
258
259 <pre> Program ::= {Definition}.
260 Definition ::= {Library} {Type} Name {Type}
261 ("type" | "proto" | {Application}).
262 Type ::= "int" | "char" | "like" Name | Name.
263 Application ::= Primitive
264 | "$" Number
265 | (Name | "do" Number) {Instr}
266 | "as" {Type} Instr
267 | "if" Instr Instr Instr
268 | "the" Name.
269 Primitive ::= &lt;&lt;an integer notated in decimal like 123&gt;&gt;
270 | &lt;&lt;a character preceded by a single quote like 'A&gt;&gt;.
271 </pre>
272
273 </body>
274 </html>
(No changes)