Rune - flesh out type support
[rune.git] / docs / grammer.html
1 <HTML>
2 <HEAD>
3 <TITLE>Rune Language Grammer</TITLE>
4 </HEAD>
5 <BODY>
6 <CENTER><H2><B>Rune Language Grammer</B></H2></CENTER>
7 <CENTER><H3><B>(c)Copyright 1996-2015, Matthew Dillon</B></H3></CENTER>
8
9 <P>
10 module:
11 <UL>
12     <I>top_stmt</I>*
13 </UL>
14
15 <P>
16 top_stmt:
17 <UL>
18     <P>
19     Top level statements synthesize the project hierarchy (which is 
20     separate from the class hierarchy) and control semantic searches
21     and object visibility in the project being compiled.  Optional scope
22     qualifiers on declarations, import, and class statements determine
23     visibility.  <B>private</B>-qualified statements can only be accessed
24     within the source module.  <B>library</B>-qualified statements can be
25     accessed within the library or program but are not visible past any self
26     containment boundaries.  This is the default.  <B>public</B>-qualified
27     statements can be accessed externally through library imports.
28     <P>
29     Note that semantic scope can extend backwards through an import unless
30     the module is asserted to be selfcontained.  For example, take the
31     following program:
32     <P>
33 <UL><PRE>
34 import "list.l" as blah;
35 import "cat.d";
36 </PRE></UL>
37     <P>
38     In this program, the "cat.d" program module can access classes
39     and certain declarations inside "list.l" by using the class path
40     <B>blah.<I>id</I></B> (or <B>list.<I>id</I></B> if we did not have
41     the <B>as</B> clause).  This is the primary method of locating classes
42     within a given program or library.  There are no ordering constraints:
43     you could easily import "cat.d" before "list.l".   In Rune, semantic
44     searches are always bottom-up and only push downward as each element
45     matches.
46     The first element of a class path is
47     matched against semantic identifiers at the current level.  If no match
48     is found we recurse up to the parent and look for the identifier there,
49     and so forth.  It is important to note that Rune does not arbitrarily
50     push into modules to locate an identifier.  For example, Rune will not
51     push into the <B>list</B> module when searching for <B>fubar</B>. 
52     Instead you have to explicitly push into the module by using 
53     <B>blah.<I>id</I></B>.  Rune provides the programmer with the ability
54     to create shortcuts using <B>typedef</B>, <B>alias</B>, and a
55     special <B>import</B> construct called <B>as self;</B>.  Rune uses these
56     features heavily in its system classes to allow the programmer to
57     do things like declare '<B>int32 x = 4;</B>' instead of
58     '<B>sys.int32 x = 4;</B>'.
59     <P>
60     The strict semantic search imposed by the language makes namespace
61     conflicts virtually non-existent.  More importantly, the namespace
62     the application uses is under the control of the application programmer
63     by virtue of being able to pull-up often-used elements, and not under
64     the control of the low-level library.
65     <P>
66     You can recursively import the same module at several points in
67     your code.  If the module is <I>self contained</I> then the module
68     never needs to semantically search above its own base Rune can use
69     a single shared instance of the module no matter how many times it
70     is imported.  This is especially useful when importing libraries
71     which have dependancies on other libraries because it allows library
72     A to import library B directly, even if you also import library B in
73     your project for other purposes.
74     You can assert that a module is self-contained by using the
75     <B>import selfcontained;</B> statement.  This also has the effect
76     of preventing Rune from searching above the module.
77     <P>
78     <I>scope_qual</I>* <B>import</B> "<I>relative-path</I>" [ <B>as</B> [ <I>id</I> | <B>self</B> ] ]";"
79     <UL>
80         <P>
81         The <B>import</B> statement glues pieces of a project together and
82         is the primary means by which a project is built.  Elements within
83         the import are accessed via the import's semantic identifier.
84         For example, if you do '<B>import "sys";</B>' then you can access
85         elements within the system library using the <B>sys</B> identifier,
86         as in '<B>sys.int32 x = 23;</B>'.
87         <P>
88         Only relative paths may be used.  The search path will always
89         begin in the directory containing the current source file.
90         Use of absolute paths are explicitly disallowed.
91         <P>
92         The statement may be used to import a directory, library, source file,
93         or other intermediate Rune file for use in your project.  By
94         default the semantic identifier used to access the import is the
95         last element of the path minus any file extension.  To allow some
96         distinction for readability within the source tree, the directory
97         itself may be prefixed with 'lib'.  So for example an import of
98         "fubar" would match a directory called "libfubar" as well as a
99         directory called "fubar".
100         <P>
101         The default identifier can be overridden with the <B>as</B> clause.
102         Modules are considered to be a special case of a variable declaration
103         so module names (the last component of the path) and identifiers must
104         start with a lower-case character.
105         <P>
106         Module paths should never specify a trailing slash when referencing
107         a directory.  In addition, a module path in an import statement
108         which references a directory may specify a suffix to provide Rune a
109         file caching hint for generated intermediate files.  In most cases
110         you do not supply a suffix for directory references and simply
111         allow Rune auto-optimize the caching itself.  A directory path must
112         never have a trailing slash and the actual directory in the filesystem
113         must not have a terminal suffix that matches anything Rune
114         understands.  A directory called "sys.l" would be illegal.
115         <P>
116         Terminal source files, libraries, objects, or other intermediate
117         files must be fully specified and may not omit their suffix.
118         For example, "cat.d".
119         <P>
120         As we have mentioned previously, semantic searches are always
121         bottom-up.  This is usually what you want but it is sometimes
122         extremely convenient to have Rune automatically push into an import
123         to locate a semantic identifier.  Rune provides a mechanism to do this.
124         By doing an '<B>import ... as self;</B>' you are telling Rune to make
125         all the semantic elements at the top level of the imported entity
126         directly available.  In this case if you '<B>import "sys" as self;</B>'
127         you can then declare its top-level types directly, as in
128         '<B>int32 x = 23;</B>', instead of '<B>sys.int32 x = 23;</B>'.
129         The <B>sys</B> library is itself 
130         hierarchical but it uses <B>typedef</B> and <B>import... as self</B>
131         to make certain deeper types directly available to you.
132         This is why <B>int32</B> can be resolved to a type.
133         A semantic search normally recurses bottom-up.  <B>If
134         you use the <I>import .. as self</I> mechanism in a module
135         the semantic search will recurse downwarn into the module looking
136         for your identifier.</B>
137         <P>
138         You can use the <B>import ... as self</B> mechanism multiple
139         times in a source file.  <B>However, Rune does not overload its
140         namespaces.  If Rune matches the first identifier in the class
141         path (<I>id.id...</I>) you specify, the semantic search will
142         not back-up again, even if it cannot resolve the remaining id's
143         in that subtree and even if another subtree would be able to
144         resolve the id path later on in the semantic search.</B>  This
145         is done on purpose, not only because overloading becomes
146         impossibly confusing when you allow that sort of thing, but also
147         because it makes tracking dependancies nearly impossible and,
148         really, Rune is designed to allow you to avoid having to overload
149         identifiers so you really should.
150         <P>
151         <B>Over-use of the as-self mechanism can cause extreme pollution
152         of the namespace and it is recommended that you use typedef and
153         alias to 'pull-up' elements to shorten identifier paths rather
154         then the as-self import mechanism which pulls up all the
155         identifiers.</B>
156         <P>
157         When importing a directory, Rune actually imports
158         "<I>directory/<B>main.d</B></I>".  <B>main.d</B> is typically
159         a small Rune source module which contains a bunch of 
160         <B>import ... as self;</B> statements to aggregate the library's
161         files together into a single cohesive whole.
162         <P>
163         <B>Namespace collisions
164         are fatal errors in Rune.  You cannot overload semantic identifiers
165         using import-as-self</B>.  As-self imports are not typically used
166         at the project level when importing third party libraries, but it
167         is often used to import the Rune language system library (called "sys")
168         in order to avoid having to specify core types using long drawn
169         own semantic paths, and almost always used within libraries to glue
170         the library together.
171         <P>
172         Multiple imports of any self-contained entity shares one instance of
173         that entity.  This feature is universally used by a self-contained
174         library to import other dependent libraries instead of depending on
175         the parent to import the required dependent libraries.  Imports may
176         be inter-dependent and generate cycles.  An infinite recursion will
177         not result.
178 <UL><PRE>
179 import "sys" as self;
180 import "cat.d";   /* code in cat.d can just use 'int' instead of 'sys.int' */
181
182 int X;          /* and so can we */
183 </PRE></UL>
184         <P>
185         Finally, note that most system support libraries are self-contained.
186         That is, they import whatever libraries they depend on, including
187         "sys", and use the as-self feature to guarentee shareability.  <B>
188         In Rune the namespace is searched semantically, NOT hierarchically by
189         class</B>.  Subclasses that you create must be accessed via the
190         module that created the subclass, not the module that created the
191         original class.
192     </UL>
193     <I>scope_qual</I>* <B>import</B> <B>selfcontained</B> ";"
194     <UL>
195         <P>
196         Asserts that the current module is self contained.  This prevents
197         any semantic search within this module from recursing above it,
198         and marks the module as being shareable which means that many
199         entities can import it and you still only have a single shared
200         instance of the module.  This feature is typically used in the
201         "main.d" for a Rune library.
202         <P>
203         In particular, note that shortcuts constructed by the parent which
204         imported the current source module will thus not be accessible.  This
205         is important due to the shareability... there can be many 'parents'
206         importing the current module.
207     </UL>
208     <I>scope_qual</I>* <B>import</B> "<I>shared_library_or_relinkable_library</I>" [ <B>as</B> <I>id</I> ] ";"
209     <UL>
210         <P>
211         Rune can import shared (.so) and relinkable/relocateable (.r) libraries
212         using the standard C dynamic link loader API.  The symbols in these
213         libraries will be bound to <B>__clang</B> scoped declarations in Rune.
214         Note that such declarations will use a truncated version of Rune's
215         semantic search mechanism to locate their proper bindings,
216         only checking the current semantic layer and parent layers
217         for imported DLL libraries.
218         <P>
219         <B>It is important to note that Rune is unable to ref-count or 
220         bounds-check C language pointers, and that there will be differences 
221         in alignment between Rune arguments and structures and C arguments and
222         structures.  For this reason any raw extensions or interfaces you make
223         to other languages should use a wrapper for each function which
224         properly translates Rune types and structures to the language, and
225         which handle all required reference counting and disposal.</B>
226     </UL>
227     <P><I>scope_qual</I>* <B>class</B> <I>id</I> "{" <I>declaration_stmt</I>* "}"
228     <P><I>scope_qual</I>* <B>subclass</B> <I>id</I> [ "."<I>id</I> ]* <B>as</b> <I>id</I> "{" <I>declaration_stmt</I>* "}"
229     <UL>
230         <P>
231         Declare a new class or subclass.  The first form creates a wholely
232         new class.  The second form subclasses the specified class.  The
233         identifier must begin with an upper-case character.
234         <P>
235         Rune uses a forest-of-classes topology, which means there is no single
236         root.  You can create new classes as easily as you can create
237         new subclasses.
238         <P>
239         Keep in mind that you do not access your class name via the
240         class hierarchy.  That is, if you create a subclass of Integer
241         called <B>FixedInteger</B> you cannot access your subclass using
242         <B>Integer.FixedInteger</B>.  In Rune identifiers are always located
243         semantically.  If you wish you can simulate a subclass hierarchy
244         using typedef, but it shouldn't be necessary.
245         <P>
246         Here is an example of a class definition that includes a procedure,
247         and a subclass definition that refines the procedure.  Note that
248         only method procedures include an object context and so only
249         method procedures can access the <B>this</B> variable.  While this
250         document is not supposed to be a tutorial, I will also note that
251         you can also have <B>global method</B> procedures where the
252         <B>this</B> variable only has access to global elements of the
253         class, and that you must explicitly use the <B>refine</B> qualifier
254         for elements in the subclass which you wish to replace elements
255         in the superclass for objects declared using the subclass, otherwise
256         any superclass functions that propogate down to the subclass without
257         being overridden will not 'see' the overrides that were made in the
258         subclass.  <B>Finally, note that variable declarations made within
259         procedures must have at least one storage or scope identifier in
260         order to differentiate between declarations and expressions or
261         statements.</B>
262         <P>
263         <UL><PRE>
264 #!/usr/local/rune/bin/rune
265 #
266 # Program to demonstrate classing and subclassing
267
268 import "sys" as self;
269 import "stdio";
270
271 class NoisyInt {
272     int x = 0;
273     method void
274     print1() {
275         stdio.stdout->show("Procedure #1 Value of X is:", this.x);
276     }
277     method void 
278     print2() {
279         stdio.stdout->show("Procedure #2 Value of X is:", this.x);
280     }
281 }
282
283 subclass NoisyInt as ReallyNoisyInt {
284     refine int x = 1;
285     refine method void 
286     print2() {
287         stdio.stdout->show("Refined procedure #2 Value of X is:", this.x);
288     }
289 }
290
291 void
292 main()
293 {
294     NoisyInt a;
295     ReallyNoisyInt b;
296
297     a.print1();         # Procedure #1 Value of X is: 0
298     a.print2();         # Procedure #2 Value of X is: 0
299     b.print1();         # Procedure #1 Value of X is: 1
300     b.print2();         # Refined procedure #2 Value of X is: 1
301 }
302         </PRE></UL>
303         <P>
304         <B>
305         It is important that you understand the difference between an
306         overloaded variable and a refined variable in a subclass.  The
307         difference has to do with the visibility of the old and new
308         versions of the variable from the point of view of the superclass.
309         </B>
310         <UL><PRE>
311 #!usr/local/rune/bin/rune
312 #
313 # Program to demonstrate overloading vs refinement in a subclass
314 #
315 #
316 import "sys" as self;
317 import "stdio";
318
319 class NoisyInt {
320     int x = 0;
321
322     method void 
323     print1() {
324         stdio.stdout->show("procedure #1 Value of X is:", this.x);
325     }
326
327     method void 
328     print2() {
329         stdio.stdout->show("procedure #2 Value of X is:", this.x);
330     }
331 }
332
333 subclass NoisyInt as ReallyNoisyInt {
334     int x = 1;          # NOTE, not refined
335
336     refine method void 
337     print1() {
338         stdio.stdout->show("Refined procedure #2 Value of X is:", this.x);
339     }
340 }
341
342 void
343 main()
344 {
345     NoisyInt a;
346     ReallyNoisyInt b;
347
348     stdio.stdout->show("Should print 0, 0, 0, 1, 1, 0");
349
350     a.print1();         # should print 0
351     a.print2();         # should print 0
352
353     b.print1();         # should print 1 
354     b.print2();         # should print 0 because this is the super class's
355                         # function and we did not refine x.
356 }
357         </PRE></UL>
358     </UL>
359
360     <FONT color="red">
361     <P><I>scope_qual</I>* <B>interface</B> <I>id</I> [ "."<I>id</I> ]* [ <I>id</I> [ "."<I>id</I> ]* ] [ <B>as</B> <I>id</I> ] "{" <I>declaration_stmt</I>* "}"
362     <UL>
363         <P>
364         An interface combines a subclass definition and instantiation 
365         (declaration) into a single entity.  Elements within the 
366         subclass have contextual access to the object the interface is
367         embedded within and the object may be passed to procedures or used 
368         in situations where the interface subclass is expected instead of
369         the object.  Use of <B>typeof()</B> on the object will match the 
370         object's type as well as the type of any interface within the 
371         object.
372         <P>
373         An interface is a form of multiple inheritance.  For convenience,
374         interfaces do not have to name the subclass or the object.  Elements
375         within the interface subclass definition may access the larger
376         object context they were embedded in through the <B>that</B>
377         identifier.  Additionally, as another convenience, <B>that</B> may
378         be used in the interface subclass's method procedures to access the
379         larger object rather then the more correct <B>this.that</B>.
380         <P>
381         <UL><PRE>
382 import "sys" as self;
383 import "stdio";
384
385 class MyCustomClass {
386     char c = 'x';
387
388     # Pretty simple, eh?  Give MyCustomClass the ability to be shown through
389     # the stdio show interface.
390     #
391     interface stdio.Showable {
392         refine void showfunc(stdio.File @fp) {
393             fp->fwrite(&that.c, 1);
394         }
395     }
396 }
397
398 void
399 main()
400 {
401     MyCustomClass x;
402     stdio.stdout->show("The char in x is: ", &x);
403 }
404         </PRE></UL>
405         <P>
406         Since Rune uses interfaces in core types to handle things like the
407         stdio show() function, care must be taken to ensure that an interface
408         does not make the physical object it is embedded within larger.  In
409         Rune, an interface subclass which itself requires no physical storage
410         (i.e. contains only globals, typedefs, aliases, and procedures)
411         does not need any additional storage to track the larger context
412         it is called through, which is why all interfaces associated with
413         core types have no physical components.
414     </UL>
415     </FONT>
416     <P><I>scope_qual</I>* <B>typedef</B> <I>declaration</I> ";"
417     <UL>
418         <P>
419         This works in a manner very similar to C except that in Rune you can do
420         all sorts of other cool things like specify default values for the
421         type (such as <B>typedef int myint = 4;</B>).
422         <B>typedef</B>'s main use is to shortcut semantic searches or to
423         provide defaults.
424         <P>
425         Typedef may not be used to typedef a procedure, but it may be used
426         to typedef a procedure pointer.  <FONT color="red">Note: procedure
427         pointers are not yet implemented.</FONT>
428         <P>
429         Note that <B>import</B> itself can be used in a limited fashion
430         to force a shortcut semantically using the <B>self</B> keyword. 
431         See '<B>import ... self</B>' for further information.  This feature
432         is typically only used on the "sys" class and for collecting
433         related source files in a library or project.
434     </UL>
435     <P><I>scope_qual</I>* <B>alias</B> <I>declaration</I> ";"
436     <UL>
437         <P>
438         An <B>alias</B> is very similar to a <B>typedef</B> but instead of
439         defining a type an alias defines a value.  Specifically, the 
440         declarative assignment operates like a macro.  So, for example,
441         in some class definition <B>X</B> you might have <B>alias
442         int c = a + b;</B>, which <B>a</B> and <B>b</B> represents fields
443         in the class and <B>c</B> represents the alias.  Aliases take no
444         space in the object and are evaluated every time they are referenced.
445         <P>
446         Aliases can be used to synthesize a shortcut out of an expression
447         and label it.  The declarative assignment in an alias declaration
448         is not optional.
449         <P>
450         Aliases return <I>rvalue</I> quantities, so an aliases may
451         also be used to create a read-only version of a field.  Instead
452         of exporting the actual (read-write) field publically, you would
453         export a public alias to a private field.
454     </UL>
455     <P><I>scope_qual</I>* <I>declaration_stmt</I>
456     <UL>
457         <P>
458         Finally, you can have normal declarations at the top level of a
459         program.  These declarations have permanent storage, like globals
460         in C.  By default a declaration at the top level has <B>library</B>
461         scope.  You can override this by specifying a specific scope
462         such as <B>private</B> or <B>public</B>.
463         <P>
464         Top level declarations do not have to be declared <B>global</B>,
465         they are automatically global.  Note that you can also declare
466         global variables within a class definition, and in that case you
467         must specify <B>global</B> so common storage is created rather
468         then per-object storage.
469     </UL>
470 </UL>
471
472 <P>
473 declaration_stmt:
474 <UL>
475     <P>[<I>scope_qual</I>|<I>stor_qual</I>] <I>declaration</I> [ "," <I>declaration</I> ]* ";"
476     <BR><I>declaration</I> "{" <I>stmt</I>* "}"
477     <UL>
478         <P>
479         These are declarative statement elements that can appear inside
480         procedures, class definitions, or at the top level.
481         <P>
482         A <I>declaration_stmt</I> is a sequence of one or more 
483         comma-delimited declarations ending with a semicolon, or a procedure
484         declaration ending with the procedure body.  Note that the first
485         form may also represent a procedure reference (a procedure
486         declaration without a procedure body), which is often used in
487         an <B>typedef</B> to partially resolve or refine procedure arguments.
488         <P>
489         <B>
490         By disallowing certain expressions at the top level Rune can 
491         distinguish between a declaration and an expression at parse time.
492         In particular, Rune assumes that a sequence like 'a * b;' is a 
493         declaration, aka like 'int *b;', not an expression.  Rune is capable
494         of distinguishing the following sequences as declarations:
495         <UL>
496             <P><I>prefix_sequence</I> <I>id</I>
497             <BR><I>prefix_sequence</I> "*"
498             <BR><I>prefix_sequence</I> "@"
499             <P>
500             Where <I>prefix_sequence</I> is:
501             <P><I>id</I> [ "." <I>id</I> ]*
502             <BR>"(" <I>anything</I> ")"
503         </UL>
504         <P>
505         If you aren't sure whether Rune can distinguish your declaration from
506         an expression you can simply use the "auto" qualifier to prefix
507         your declaration.  The distinguishment code is only used in
508         executable sections.  The elements at the top level of a file or
509         within a class or subclass definition are always declarations.
510         </B>
511     </UL>
512     <FONT color="ref">
513     <P><I>scope_qual</I>* <B>exception</B> <I>id</I> "=" <I>string</I> ";"
514     <UL>
515         <P>
516         An <B>exception</B> is basically a string constant.  The declaration
517         names the exception and must assign a constant string as the value.
518         In addition, the string will have a unique address (even if multiple
519         exceptions specify the same string).
520         <P>
521         Exception declarations are used to construct rendezvous addresses
522         for the <B>raise</B> and <B>catch</B> statements, and may also be
523         referenced as constant pointers to constant strings.
524     </UL>
525     </FONT>
526 </UL>
527
528 <P>
529 declaration_list:
530 <UL>
531     <P>[ <I>declaration</I> [ "," <I>declaration</I> ]* ]
532     <UL>
533         <P>
534         A <I>declaration_list</I> is a comma-delimited list of declarations
535         that usually appear as part of a compound type or a procedure's
536         argument list.
537         <P>
538         The list can be empty.  Note that a <I>declaration_stmt</I> is
539         essentially a <I>declaration_list</I> with at least one element,
540         and terminated by a semicolon.
541     </UL>
542 </UL>
543
544 <P>
545 declaration:
546 <UL>
547     <P>[ <I>procedureClass</I> ] <I>type</I> [ <I>decl</I> ]* [ "=" <I>exp</I> ]
548     <UL>
549         <P>
550         A <I>declaration</I> consists of a type, a potentially complex set of 
551         declarators that may include an identifier, and an optional 
552         assigned expression.  Note that assigned expressions are not allowed
553         for procedure definitions (this is where the procedure body would
554         normally go).  A procedure definition's body is actually parsed
555         as part of a <I>declaration_stmt</I>, not a <I>declaration</I>.  
556         A <I>procedureClass</I> sequence may only be used when declaring
557         a procedure.
558         <P>
559         Assigned expressions represent different things depending on the
560         context.  In a procedure argument declaration an assigned expression
561         represents a default value for the argument, making the argument
562         optional.  In a storage declaration the assigned expression
563         represents the initial state of the storage.  In a class or
564         compound type definition the assigned expression represents 
565         the default initialization for an element in the class when
566         the class is instantiated (and can be overriden by subclasses
567         or when the class is instantiated).
568         <P>
569         Default assignment may reference other elements in the object
570         directly.  For example, you can have a class with fields
571         <B>A</B>, <B>B</B>, and <B>C</B> and do something like:
572         <B>int C = A + B;</B> for C.  Defaults are assigned in the same
573         order in which they were declared.  If no default is specified,
574         the type's default is used (a type can have a default as well,
575         typically created via typedef).  If no type default exists, the
576         element will be zero'd.  Pointer declarations will be set to NULL
577         (in Rune pointers are ref-counted so we have to initialize a reference,
578         even though the pointer value is NULL).  <B>Declarations are never
579         left uninitialized.  If no other defaults exist, the contents of
580         an object will be zerod.  This is holds true even for declarations
581         made on the stack.  Rune will attempt to optimize-away pre-zeroing
582         when code analysis proves that a write occurs before a read.</B>
583         <P>
584         Declarators modify the base type.  See <I>decl</I>.
585     </UL>
586 </UL>
587
588 <P>
589 type:
590 <UL>
591     <P><I>stor_qual</I>* "(" <I>declaration_list</I> ")"
592     <UL>
593         <P>
594         A type may be compound, made up of a tuple of other types.  The
595         compound type is treated in a manner similar to a class.
596     </UL>
597     <P><I>stor_qual</I>* <I>id</I> [ "." <I>id</I> ]*
598     <UL>
599         <P>
600         A type may be specified by a sequence of scoped identifiers.  <B>Note
601         that the sequence does not represent a hierarchical class path
602         but instead represents a semantic search sequence.</B>
603         The first identifier is typically located in our current scope and
604         we then recurse down semantically (for example, through import 
605         identifiers, class definition identifiers, and typedefs) until we
606         reach the final element.  This final element represents our type.
607         <P>
608         It is quite common for Rune programmers to use <B>typedef</B> to pull
609         subclasses into their parent classes, making this sequence appear
610         to be class-hierarchical, but it is only an illusion.
611     </UL>
612 </UL>
613
614 <P>
615 decl:
616 <UL>
617     <P>
618     A <I>decl</I> specifies the semantic name and type qualifiers associated
619     with a type.  Declarations build the type up from left to right until
620     you hit an identifier or procedure arguments, after which the type is
621     built up from right to left.  So, for example, something like
622     <B>const int * const fubar[2][10]</B> is an array 2 of an array 10
623     of a constant pointer to a constant int, and <B>int *fubar *(int a, 
624     int b)</B> would be a pointer to a procedure taking two arguments and
625     returning a pointer to an integer.  <B>Note that Rune does not use the
626     C-style int (*ptr)(int, int) form to specify a procedure pointer.</B>
627     <FONT color="red">This release of the Rune language does not implement
628     procedure pointers.</FONT>
629
630     <P><I>id</I> [ "." <I>id</I> ]*
631     <UL>
632         <P>
633         Specify the identifier for a declaration.  Usually only a single
634         identifier is specified.  Multiple dot-separated identifiers
635         are allowed for top-level declarations in order to move the
636         declaration's semantic context into a class.  This allows you
637         to define a class and then place various complex declarations (like
638         large procedures) outside of that class but within the same file.
639         For example:
640         <P>
641         <UL><PRE>
642 class fubar {
643 }
644
645 int fubar.func() { ... }
646         </PRE></UL>
647         <P>
648         Such identifier sequences are resolved by the parser and may only
649         be reverse-referenced.  We do not search beyond PRIVATE scope (that
650         is, the parser only looks within the current file to resolve the
651         id prefix).  This allows Rune to isolate the results of the main 
652         language parsing pass in order to be able to quickly generate
653         and use pre-parsed intermediate file images.
654         <P>
655         At some future date I may extend this capability to LIBRARY scope.
656     </UL>
657     <P>"(" <I>declaration_list</I> ")"
658     <UL>
659         <P>
660         A procedure taking the specified arguments and returning the type
661         built up so far.  For example, <B>int fubar ( int a, int b );</B>.
662     </UL>
663     <P> "[" <I>exp</I> "]"
664     <UL>
665         <P>
666         Array N of some type.  Note that when you reference an array in
667         Rune you are referencing the entire object, not a pointer to the first
668         element.  In C when you reference an array you are generally,
669         but not always, referencing a pointer to the first element.
670     </UL>
671     <P>"*"
672     <UL>
673         <P>
674         A pointer to a type.  A pointer points to an object of
675         the instantiated type and cannot be bound to objects of any
676         other instantiated type, not even to a subclass of the
677         particular type.
678     </UL>
679     <P>"@"
680     <UL>
681         <P>
682         A reference to a type.  References are similar to pointers but
683         can be dynamically rebound to subclasses of the type as well as to
684         the type itself.  The type, in this case, is usually refered to as
685         the <I>superclass</I>.  All operations performed through reference
686         variables enforce the superclass's API.  That is, you cannot
687         directly access non-refined extensions made in the actual bound
688         object but must instead access them indirectly through refined
689         method calls whos APIs are specified in the superclass.
690         <P>
691         <B>Rune distinguishes between subclass binding inferred by the
692         class hierarchy and subclass bindings created through dynamic
693         bindings to reference types.  Rune will provide a guarantee to
694         the programmer to allow the programmer to control bloating of the
695         executable due to versioning.</B>
696         <P>
697         Rune will guarantee the use of procedure versioning for procedures
698         generated from class and subclass statements, and will guarantee the
699         use of a far more compact indirect-call-through-type for code
700         within a procedure which operates on a dynamically-bound pointer.
701         This means that code acting on a dynamically bound type may actually
702         be tacked onto the type meta-data as an indirect call instead of
703         being inlined.  This indirect call does not make the type itself any
704         larger... it's added to the type meta-data (the description of the
705         type), not to the data object.
706     </UL>
707 </UL>
708
709 <P>
710 stmt:
711 <UL>
712     <P>
713     Executable statements appearing inside procedures
714     <P>
715     "{" <I>stmt</I>* "}"
716     <UL>
717         <P>
718         A statement block or sub-block.  Upon entering a sub-block the local
719         declaration space will be re-initialized.  Upon exiting a sub-block
720         the local declaration space will be dereferenced (any 
721         referece-counted pointers will be cleared and dereferenced, for
722         example).
723     </UL>
724     <P>
725     <I>exp</I> ";"
726     <UL>
727         <P>
728         An expression as a statement.  The expression must return void.
729     </UL>
730     <P>
731     <I>declaration_stmt</I>
732     <UL>
733         <P>
734         A declaration as a statement may occur inside procedures at any
735         point.  Note the storage is allocated at the nearest semantic block
736         but any assignment occurs at the point the statement is executed.
737     </UL>
738     <P><B>for</B> "(" <I>stmt</I> <I>exp</I> ";" <I>exp</I> ")" <I>stmt</I>
739     <BR><B>while</B> "(" <I>exp</I> ")" <I>stmt</I>
740     <BR><B>until</B> "(" <I>exp</I> ")" <I>stmt</I>
741     <BR><B>do</B> <I>stmt</I> <B>while</B> (" <I>exp</I> ")" ";"
742     <BR><B>do</B> <I>stmt</I> <B>until</B> (" <I>exp</I> ")" ";"
743     <UL>
744         <P>
745         Various loop statements.  Do not be confused by the apparent missing
746         semicolon in the <B>for</B>.  Remember that <I>stmt</I> typically
747         terminates with a semicolon.  The format of these looping statements
748         is approximately the same as in C.
749         <P>
750         Loop statements are contained within their own semantic block, which
751         means that you can do things like <B>for(int i = 0; i < 100; ++i)
752         ...</B>
753     </UL>
754     <P><B>break</B> [ <B>loop</B> | <B>switch</B> | <B>if</B> | <B>case</B> | <B>block</B> | <I>empty</I> ] ";"
755     <BR><B>continue</B> [ <B>loop</B> | <B>switch</B> | <B>if</B> | <B>case</B> | <B>block</B> | <I>empty</I> ] ";"
756     <UL>
757         <P>
758         These statements behave as you would expect in C but have extensions
759         that allow you to break or continue as if you were at a particular
760         semantic level.  For example, you can <B>continue switch</B> to
761         re-evaluate and restart a switch statement.
762         <P>
763         Extended break and continue statements should be used only in
764         situations where the logic is obvious.  Rune does not implement
765         multi-level breaks and continues on purpose.  Anything more complex
766         must use the exceptions (see <B>raise</B>). 
767         <P>
768         <B>Rune does not implement goto.</B>
769     </UL>
770     <P><B>switch</B> "(" <I>exp</I> ")" "{" <I>case_stmt</I>* "}"
771     <BR><B>switch</B> "(" <I>type</I> ")" "{" <I>case_stmt</I>* "}"
772     <UL>
773         <P>
774         This statement evaluates the expression and matches it against a
775         case/default list, then jumps to the appropriate case or default.
776         <P>
777         You can also switch on a type, typically through the use
778         of the <B>typeof()</B> construct.  In this situation, case
779         statements must also resolve to types, also typically through the
780         same construct.  This feature is most often used when processing a
781         var-args procedure.
782     </UL>
783     <P><B>if</B> "(" <I>exp</I> ")" <I>stmt</I> [ <B>else</B> <I>stmt</I> ]
784     <UL>
785         <P>
786         The expression must return either a boolean or a type that
787         can be cast to a boolean. <B>Rune treats booleans as a separate
788         numeric class from integers.  While all numeric types have
789         casts available to convert to a boolean, the functionality is
790         strictly limited to common-sense cases.  Pointers do not auto-cast
791         to boolean and must be explicitly compared to NULL.</B>
792     </UL>
793     <P><B>return</B> [ "(" [ <I>id</I> ":" ] <I>exp</I> [ "," [ <I>id</I> ":" ] <I>exp</I> ]* ")" ] ";"
794     <UL>
795         <P>
796         Return from procedure.  If the procedure returns <B>void</B> you
797         can use <B>return;</B> or <B>return();</B>.  If the procedure 
798         is running as its own thread the thread will be terminated.
799         <P>
800         You may supply a compound expression to generate a multi-valued
801         return.  Compound expressions may include element identifiers.
802     </UL>
803     <P><B>result</B> [ "(" [ <I>id</I> ":" ] <I>exp</I> [ "," [ <I>id</I> ":" ] <I>exp</I> ]* ")" ] ";"
804     <UL>
805         <P>
806         Set the return value for the procedure and continue running.
807         <P>
808         <B>result</B> has special consequences if the procedure is threaded.
809         When a call to a threaded procedure is made the caller stalls until
810         the threaded procedure returns a result.  The threaded procedure can
811         return a result with <B>result</B> and continue running (so now both
812         the caller and the threaded procedure are running).  
813         <B>However, since the procedure arguments and return value are part
814         of the caller's context, the threaded procedure cannot access them
815         after calling <I>result</I>.  You must copy any arguments you
816         still wish to access prior to calling <I>result</I>.</B>
817         <P>
818         You may supply a compound expression to generate a multi-valued
819         return.  Compound expressions may include element identifiers.
820     </UL>
821     <FONT color="red">
822     <P><B>thread_schedule</B> [ <B>preempt</B> | <B>nopreempt</B> | <B>immediate</B> ] ";"
823     <UL>
824         <P>
825         Set the thread scheduling mode, force a thread switch, or allow a 
826         natural thread switch.  If no arguments are specified Rune will do a 
827         natural thread switch, which means it will only switch threads if
828         more then a certain number of cycles have elapsed running the current
829         thread.  If <B>immediate</B> is specified, Rune will do an
830         immediate thread switch (which can be quite expensive).
831         If <B>preempt</B> is specified, preemption is turned on.
832         Preemption is essentially natural scheduling occuring at any time
833         without additional prompting.
834         <B>nopreempt</B> turns off preemption.
835         <P>
836         <B>Turning on preemption is not recommended unless you are doing a
837         large, completely self-contained calculation.</B>
838         <P>
839         The preemption mode is adjusted on a procedure-by-procedure basis.
840         Unless you specify <B>preempt</B> scope for a procedure, preemption
841         is automatically turned off on entry to any procedure.  The prior
842         mode will be restored on return so, for example, a
843         <B>thread_schedule preempt;</B> statement in a procedure will not
844         change the scheduling mode of the caller of the procedure.   What
845         this means, in short, is that you have to worry about preemption
846         related races only in those procedures for which preemption is 
847         explicitly enabled, and not in any procedure calls made from
848         those procedures.
849     </UL>
850     <P><B>raise</B> [ <I>exp</I> [ "," <I>exp</I> ] ] ";"
851     <P><B>raise</B> <I>id</I> ";"
852     <UL>
853         <P>
854         Raise the specified exception along with an optional sub-code.
855         Both the exception and the sub-code must generally refer to
856         a <B>exception</B> declaration.  These are special declarations which
857         resolve to unique const string pointers.  <B>catch</B> sequences
858         compare the unique addresses and not the contents of the strings.
859         <P>
860         It is also acceptable to specify an ad-hoc identifier which matches
861         against an accessible <B>catch</B> in the same procedure.
862         <P>
863         In its degenerate form, this statement chains an existing active
864         exception and is typically used to allow <B>catch</B> bodies to
865         chain semantically.
866         Examples include, for example, <B>sys.IOERROR</B>, or perhaps
867         something as simple as <B>MYAPPIOERROR</B>, or in an ad-hoc
868         case perhaps something like <B>raise failed;</B>.
869         <P>
870         The exception raise propagates forward semantically looking for
871         a matching <B>catch</B>, essentially falling through code blocks
872         until it finds what it wants.  When a procedural boundary is
873         reached the procedural context is popped and the search continues
874         in the caller.  <I><B>A normal procedural return does not
875         occur!</B></I>
876         Exceptions which cross a thread boundary cause the thread to exit
877         and the exception to be held for the reaper to interrogate.  It
878         will not cause an exception IN the reaper.
879         <P>
880         <B>raise</B>/<B>catch</B> sequences are typically used to propagate
881         serious error conditions, such as a memory allocation failure
882         or I/O error, but not nominal failures such as a short-read or EOF
883         on a file.
884         <P>
885         These sequences can also be used as a poor-man's forward-goto when
886         <B>break;</B> can't reach, such as if you desire to break out of
887         multiple loop levels.  The language grudgingly allows this behavior
888         and at least forces the programmer to use this more explicit mechanism
889         rather than an ephermal multi-level <B>break</B> or <B>continue</B>
890         whos complexity could get lost in a large section of code.  We
891         respectfully suggest you only use it when you desire to unwind
892         the procedure and return due to an error.  Also note that exception
893         handling is not considered a critical performance code path.
894     </UL>
895     <P><B>catch</B> [ <I>exp</I> [ "," <I>exp</I> ]* ] "{" <stmt>* "}"
896     <BR><B>catch</B> [ <I>exp</I> [ "," <I>exp</I> ]* ] ";"
897     <UL>
898         <P>
899         Catch matching exception(s) which occurs prior to the <B>catch</B>
900         statement.  If no identifiers are specified, all exceptions will
901         be caught.  The body is only executed if a matching exception jumps
902         into it.   Note that the expressions must resolve to <B>exception</B>
903         declarations.  Simply specifying the same string will not work.
904         Exception handling compares string pointers directly, not their
905         contents.
906         <P>
907         If your code falls through the block the exception state is lost
908         and normal execution is resumed at that point.  This mechanic is
909         most typically used for forward-failure processing using an ad-hoc
910         <B>raise</B>/<B>catch</B> sequence.  Any normal statement which exits
911         the catch body, such as a <B>break</B> or <B>continue</B>, also
912         resumes normal execution.  Your code can also elect to chain the
913         currently active exception by issuing a <B>raise;</B> inside the
914         catch body, or even by issuing a completely new <B>raise</B>.
915         <P>
916         If your exception code executes something which causes another
917         exception you can catch the secondary exception within your exception
918         code by emplacing additional <B>catch</B> statements within your
919         catch block.  If the embedded catch falls through to the original
920         catch, the new exception is lost and the original exception is
921         reactivated.  Note that an uncaught secondary exception will break
922         out of your catch and continue chaining up searching for a matching
923         catch.  An exception occuring inside a catch body will not match
924         against or restart it.
925         <P>
926         Multiple matches against the exception code may be specified.
927         You must process any sub-code from within your catch, there is no
928         language mechanism to match the sub-code.  You may access the
929         exception code and the sub-code from within the body using
930         <B>.code</B> and <B>.subcode</B>.  Both are unique string pointers.
931     </UL>
932     </FONT>
933 </UL>
934
935 <P>
936 case_stmt:
937 <UL>
938     <P>
939     <B>case</B> <I>exp</I> ":" <I>stmt*</I>
940     <BR>case</B> <I>type</I> ":" <I>stmt*</I>
941     <UL>
942         <P>
943         A case inside of a switch.  Case statement usually finishes up with
944         a <B>break</B> statement.  Without one it will fall through to the
945         next <B>case</B> or <B>default</B>, or fall off the end of the
946         <B>switch</B>.
947         <P>
948         Case statements are contained within their own semantic block, which
949         means that you can do things like <B>case blah: int i ...</B>.
950         Declarations are valid only within the case and will be released
951         when you leave the case.
952     </UL>
953     <P>
954     <B>default</B> ":" <I>stmt*</I>
955     <UL>
956         <P>
957         A default inside of a switch.  Similar to <B>case</B> but this label
958         takes the default if none of the cases match.  The fall-through
959         works the same way.
960         <P>
961         Default statements are contained within their own semantic block, which
962         means that you can do things like <B>case blah: int i ...</B>.
963         Declarations are valid only within the case.
964     </UL>
965 </UL>
966
967 <P>exp:
968 <UL>
969     <BR><I>id</I>
970     <UL>
971         <P>A variable identifier.
972     </UL>
973
974     <BR><I>constant</I>
975     <UL>
976         <P>An integer, character, or floating point constant.
977     </UL>
978
979     <BR><I>string</I>
980     <UL>
981         <P>
982         A quoted string.  Quoted strings are classed as an array of
983         const char but will auto-cast to a pointer to a const char
984         if necessary.
985     </UL>
986
987     <BR><B>self</B>
988     <UL>
989         <P>
990         The <B>self</B> identifier, when not used as a keyword, is the
991         compound object representing the current procedure's arguments.
992         This identifier is used almost exclusively to access extended
993         (varargs) arguments, since other procedure arguments can be
994         accessed directly by name.
995     </UL>
996
997     <BR><B>this</B>
998     <UL>
999         <P>
1000         The <B>this</B> identifier only exists in method procedures.  It is
1001         the (typically invisible) first argument of the method procedure
1002         representing the object the procedure was called through.
1003         For <B>global</B> method procedures there is no object context
1004         and <B>this</B> represents the type the procedure was called through
1005         rather then the object it was called through, giving you access
1006         to globals within the type's class.  <B>this</B> is a <B>lvalue</B>
1007         <P>
1008     </UL>
1009     <BR><B>super</B>
1010     <UL>
1011         <P>
1012         The <B>super</B> identifier represents the method's object from the
1013         point of view of the superclass.  You can access the previous version
1014         of a refined element this way, but your access to such elements
1015         is restricted to procedures only.  There is no way to access the
1016         'original' storage that you have refined because it does not exist
1017         in the object, only your refined storage exists.  The same
1018         could be said for procedure declarations if not for the special
1019         case that Rune implements to give you access to the original procedure.
1020         <P>
1021         The difference between overloading an element (not using
1022         <B>refine</B>) in a subclass, and refining an element in a subclass
1023         that exists in the superclass, all comes down to how the object
1024         is viewed from the point of view of the superclass.  This is the
1025         point of view that functions declared in the superclass (and not
1026         refined in the subclass) will have, as well as the point of view
1027         that an object accessed through reference type declaring
1028         the superclass will have.
1029         <P>
1030         If you overload a method or declaration rather then refine it then
1031         it does not exist from the point of view of the superclass... the
1032         original declaration will be accessed.  If you refine the method
1033         instead, however, the superclass will see your refinements in the
1034         context of the superclass.  Please refer to the <B>subclass</B>
1035         statement above for a more detailed explanation.
1036     </UL>
1037
1038     <BR><B>typeof</B> "(" <I>exp</I> ")"
1039     <BR><B>typeof</B> "(" [<I>scope_qual</I>]* [<I>stor_qual</I>]* <I>type</I> ")"
1040     <UL>
1041         <P>
1042         Converts an expression into a type or manipulates an existing type.
1043         This operator may not be used to instantiate the type, but it may
1044         be used to access global elements within the type via "." and the
1045         result of <B>typeof()</B> may be used in <B>switch</B> and
1046         <B>case</B> statements (when switching on varargs arguments,
1047         for example).
1048         <P>
1049         Note that in a switch/case statement Rune uses relaxed rules when
1050         doing type comparisons and will match even if there are differences
1051         in the <B>lvalue</B>, <B>const</B>, and <B>volatile</B> qualifiers
1052         to the types.
1053         <P>
1054         This construct may also be used to help cast intermediate elements
1055         of an expression, for example <B>(typeof(a))(b + c)</B>.
1056     </UL>
1057
1058     <BR><B>sizeof</B> "(" <I>exp</I> ")"
1059     <BR><B>sizeof</B> "(" <I>scope_qual</I>* <I>type</I> ")"
1060     <UL>
1061         <P>
1062         Returns the physical storage required to hold the expression's
1063         type or the specified type.
1064         <P>
1065         Follows rules similar to <B>typeof()</B>.
1066     </UL>
1067
1068     <BR><B>arysize</B> "(" <I>exp</I> ")"
1069     <BR><B>arysize</B> "(" <I>scope_qual</I>* <I>type</I> ")"
1070     <UL>
1071         <P>
1072         The expression or type must resolve into an array.  Not a pointer,
1073         an array.  The number of declared elements in the array will be
1074         returned.
1075         <P>
1076         Follows rules similar to <B>typeof()</B>.
1077     </UL>
1078
1079     <BR><I>compound_exp</I>
1080     <UL>
1081         <P>
1082         A parenthesized expression such as <B>(1, 2)</B> is a compound
1083         expression.  Compound expressions may have several elements.
1084         <B>Note that in Rune, there is no 'comma' operator.  The operator
1085         instead denotes a compound expression</B>.
1086         <P>
1087         A compound expression has an associated compound type (which
1088         is specified in a similar manner through comma delineation).
1089         Compound expressions are not vectorized in Rune.  That is, you
1090         cannot use an operator defined for a normal non-compound
1091         type like <B>int</B> on a compound type made up of <B>int</B>s.
1092         You can, however, define and use operators designed
1093         to operate on specific compound types.
1094         <P>
1095         A normal parenthesized expression such as <B>(23)</B> is simply
1096         a degenerate case of a compound expression.
1097     </UL>
1098
1099     <BR> "(" (<I>scope_qual</I>|<I>stor_qual</I>) <I>type</I> ")" <I>exp</I>
1100     <BR> "(" <B>typeof</B> "(" <I>exp</I> ")" ")"
1101     <UL>
1102         <P>
1103         Cast the expression to the specified type.
1104         <P>
1105         Rune also allows casts of the <B>typeof</B> construct here.  Although
1106         the use case can be somewhat confusing to read, there is merit to
1107         allowing the case.
1108         <P>
1109         Unlike C, Rune will not allow you to arbitrarily cast between types,
1110         nor will Rune automatically normalize integer arguments for operators. 
1111         For convenience certain functions such as shift operators and pointer
1112         arithmatic can operate on mixed types, but most pure arithmatic
1113         operators require the same numeric type.
1114         <P>
1115         Type casts must be used when extracting an element from varargs,
1116         and must match the type of the element.  This is typically combined
1117         with a <B>switch</B> / <B>case</B> sequence on the element type.
1118     </UL>
1119
1120     <BR> "(" [<I>scope_qual</I>]* [<I>stor_qual</I>]* <I>type</I> ")" "." <I>id</I>
1121     <UL>
1122         <P>
1123         This construct is typically used to access global elements related
1124         to a particular type, but is generally only used to resolve
1125         pointer type fields (verses elements of the underlying class).
1126         For example <B>(const char *).NULL</B> gives you a NULL char
1127         pointer.
1128         <P>
1129         This method is not generally used to access globals in a base class
1130         because a more convenient direct construct exists for that.
1131         For example <B>Ship.some_global_element</B>.
1132         <P>
1133         Other methods of accessing NULL: typedef a pointer and access NULL
1134         via the typedef identifier, like <B>typedef const char *string_t; 
1135         ... string_t.NULL</B>, or go through an object, like
1136         <B>procedure (... const char *str) { ... if (str == str.NULL) ... }</B>.
1137         <P>
1138         There is also a global <B>NULL</B> Which corresponds to the C 
1139         equivalent of <B>(void *)NULL</B>, which you can use in any
1140         situation where Rune knows what pointer type to cast it to,
1141         including simple pointer comparisons against <B>NULL</B>.
1142     </UL>
1143
1144     <BR> <I>exp</I> "." <B>new</B> "(" [ <I>exp</I> ] ")"
1145     <UL>
1146         <P>
1147         Heap storage is allocated for the lvalue represented by the
1148         first <I>exp</I>.  This is typically an initially NULL pointer
1149         variable or NULL reference variable.  This can also be used to
1150         reallocate an object.  Any prior object will be dereferenced and
1151         replaced with a new object.
1152         <P>
1153         The <B>new</B> method is defined in the Pointer class with an
1154         internal binding, hence why you use ".".  You are not indirecting
1155         through the (likely NULL) pointer, but instead executing a class
1156         function ON the pointer object itself as an lvalue.
1157         <P>
1158         Heap objects are automatically freed when the last pointer reference
1159         to them goes away, typically by setting the pointer(s) to some other
1160         object or to NULL.
1161         <P>
1162         You can specify the number of objects to allocate (aka an array)
1163         as an argument to <B>new</B>.  If not specified, one object is
1164         allocated.
1165         <P>
1166         Heap allocation works with both pointers and reference types.
1167         However, since array indexing and pointer arithmatic does not work
1168         with reference types, allocating more then one reference type is
1169         not generally useful.
1170         <P>
1171         This construct does not give you an array-of-objects type, it simply
1172         gives you an array of objects with the variable pointing at the first
1173         entry.  You can manipulate the pointer with pointer arithmatic but
1174         a fatal error will occur if you attempt to indirect through an
1175         out-of-bounds pointer.
1176         <P>
1177         The actual class or subclass object allocated when you use
1178         <B>new</B> on a reference type or a pointer depends on what was
1179         last assigned to the reference type.  If a generic NULL was
1180         assigned, the base class of the reference type will be allocated.
1181         This is not always useful.  This function is almost exclusively
1182         used with pointers and not with reference types.
1183     </UL>
1184
1185     <BR>"*" <I>exp</I>
1186     <UL>
1187         <P>
1188         Pointer or reference indirection.  <I>exp</I>'s type must
1189         be a pointer to storage or a reference to storage.  The operator
1190         will indirect through the pointer and return the object it
1191         was pointing to.
1192         <P>
1193         The returned object will be an lvalue.
1194     </UL>
1195
1196     <BR>"&" <I>exp</I>
1197     <UL>
1198         <P>
1199         Address of.  The <I>exp</I> must be an lvalue.  The address of the
1200         object is taken, returning a pointer object.  The result is always
1201         an rvalue.
1202         <P>
1203         The "&" operator may also be combined with a procedure call expression
1204         to partially resolve procedural arguments, producing a new procedure.
1205         The procedure being partially resolved is not called in this case.
1206         For example, if you have a procedure <B>int fubar(int a, int b,
1207         int c);</b> then <B>&fubar(a:23)</B> results in a pointer to a
1208         procedure taking two arguments, <B>b</B> and <B>c</B>. 
1209         <FONT color="red">Note that procedural function pointers have not
1210         yet been implemented, so this feature does not yet work.</FONT>
1211     </UL>
1212
1213     <BR><I>exp</I> "=" <I>exp</I>
1214     <UL>
1215         <P>
1216         Assignment.  The right hand side is copied to the left hand side.
1217         The LHS must be an lvalue.  A chain of assignments will execute
1218         right-to-left.
1219         <P>
1220         The internal implementation may wind up being somewhat more complex.
1221         If you are assigning a pointer previously associated with a heap
1222         object, the original heap object is dereferenced.  If the new object
1223         is a pointer to a heap object then the new object's ref count will
1224         be bumped.  If you are assigning whole objects, then the same thing
1225         happens to pointer elements emebedded in those objects (or embedded 
1226         in elements embedded in those objects, etc...).
1227     </UL>
1228
1229     <BR><I>exp</I> "->" <I>id</I>
1230     <UL>
1231         <P>
1232         Structural indirection.  The left hand side must resolve to a pointer
1233         to a class.  The right hand side identifies an element in the
1234         class.  The element does not necessarily have to represent
1235         storage.  For example, it can represent a typedef'd type or a 
1236         procedure.
1237         <P>
1238         If the element represents storage, then the result of this operator
1239         is the storage in question, an lvalue.
1240         <P>
1241         If the element represents a typedef, then the result of this
1242         operator is a type (for example that you might use in a declaration).
1243     </UL>
1244
1245     <BR><I>exp</I> "." <I>id</I>
1246     <UL>
1247         <P>
1248         Structural selection.  The left hand side must resolve to a
1249         grouped object, such as a compound type, a class, or <B>self</B>
1250         (representing the procedure's arguments and used almost solely
1251         to deal with var-args).
1252         <P>
1253         The right hand side identifies an element in the class.  The element
1254         does not necessarily have to represent storage.  For example, it can
1255         represent a typedef's type or a procedure.
1256         <P>
1257         If the element represents storage, then the result of this operator
1258         is the storage in question, an lvalue.  <B>Only globally scoped
1259         storage is available when selecting via a type.  Local storage is
1260         available only when selecting via an object</B>
1261         <P>
1262         If the element represents a typedef, then the result of this
1263         operator is a type (for example that you might use in a declaration).
1264         <P>
1265         A number of special identifiers may be used on the right hand side.
1266         These identifiers mostly apply to grouped objects like compound
1267         types, arguments (i.e. <B>self</B>), and classes.  However,
1268         the <B>NULL</B> identifier applies to pointers.
1269         <UL>
1270             <P>
1271             <B>NULL</B> - When applied to a pointer this generates a NULL
1272             pointer of the specified type.   Note that this is different
1273             from the global NULL pointer (which is a NULL pointer to a void
1274             type).  A type-specific NULL pointer is a very different beast
1275             since you can access global data and non-method procedures
1276             specific to a type through it.
1277             <P>
1278             <B>__count</B> - An integer representing the number of elements
1279             in the object.
1280             <P>
1281             <B>__data[<I>exp</I>]</B> - The specified element in the object.
1282             You can do two things with this.  First, you can access the
1283             element within a <B>typeof()</B> and switch on its type. 
1284             Second, you can access the data itself but you must explicitly
1285             cast it to a compatible type.  This is typically done inside
1286             a <B>switch</B>/<B>case</B>.
1287             <P>
1288             <B>__varcount</B> - same as <B>__count</B> but only counts
1289             extended arguments in varargs procedures.
1290             <P>
1291             <B>__vardata[<I>exp</I>]</B> - Same as <B>__data</B> but only
1292             applies to extended arguments in varargs procedures.
1293             <P>
1294             <B>__typeid</B> - (future) A unique integer identifying a type.
1295                     <FONT color="red">Feature not yet implemented</FONT>.
1296             <P>
1297             <B>__typestr</B> - (future) A string representing the resolved type.
1298                     <FONT color="red">Feature not yet implemented</FONT>.
1299         </UL>
1300     </UL>
1301
1302     <BR><I>operator</I> <I>exp</I>
1303     <UL>
1304         <P>
1305         A unary operator acting on an expression.  Unary operators have
1306         a fixed precedence.  Note that Rune supports only prefix operators
1307         such as <B>++x</B>.  Rune does not support postfix operators such
1308         as <B>x++</B>.
1309         <P>
1310         If the operator requires an lvalue, then <I>exp</I> must be an
1311         lvalue.  If the operator returns an lvalue, then the result may
1312         be used in a larger expression that requires an lvalue.
1313     </UL>
1314
1315     <BR><I>exp</I> <I>operator</I> <I>exp</I>
1316     <UL>
1317         <P>
1318         A binary operator acting on an expression.   Binary 
1319         operators have specific precedences which are non-negotiable.
1320         This allows Rune to parse programs without needing knowledge outside
1321         the source file being operated on and also allows programmers to
1322         understand how expressions are evaluated across the board.  Rune
1323         is complex enough as it is, we do not need dynamic operator
1324         precedence to muddy the waters further.
1325         <P>
1326         If the operator requires an lvalue, then <I>exp</I> must be an
1327         lvalue.  If the operator returns an lvalue, then the result may
1328         be used in a larger expression that requires an lvalue.
1329     </UL>
1330
1331     <BR><I>exp</I> "[" <I>exp</I> "]"
1332     <UL>
1333         <P>
1334         Index into an array, returning an element of the array.  The left
1335         hand side must be an array or a pointer.  The right hand side will
1336         be cast to a 32 bit signed integer.
1337         <P>
1338         This operator returns an lvalue.
1339     </UL>
1340
1341 </UL>
1342
1343 <P>scope_qual:
1344 <UL>
1345     <P>
1346     Scope qualifiers are bound to the declaration itself rather then to
1347     the type(s) making up the declaration.  A type does not have scope,
1348     but a declaration does.  However, certain scope qualifiers may
1349     modify how an underlying type is created.  Also note that when we 
1350     specify that something is accessible, it must still fall within
1351     the semantic search of the entity attempting to access it.  So,
1352     for example, a variable declaration in procedure A is not directly 
1353     accessible by procedure B no matter how you scope it.
1354     <P>
1355     <BR><B>private</B>
1356     <UL>
1357         <P>
1358         The declaration may only be accessed from the current source
1359         module and by modules imported by the current source module,
1360         so long as the imported modules are not self contained.
1361         <P>
1362         When used within a class definition, the declaration may only be
1363         accessed by elements within that class definition.  Elements include
1364         procedures associated with the class and default assignments for
1365         other elements.  Subclasses of a class will not have any access to
1366         the declaration and will not be able to refine it.
1367     </UL>
1368     <BR><B>library</B>
1369     <UL>
1370         <P>
1371         The declaration may be accessed from the current source module,
1372         from imports made by the current source module, and by sibling
1373         imports, so long as those imports are not self contained.
1374         For example, if a library's <I>main.d</I> imports two source 
1375         modules <I>able.d</I> and <I>charlie.d</I>, then <I>charlie.d</I>
1376         will be able to access a library scoped variable declared
1377         in <I>able.d</I>.
1378         <P>
1379         When used within a class definition, the declaration may be accessed
1380         by elements within that class definition, by the current source 
1381         module, from imports made by the current source module, and by
1382         sibling imports.
1383         <P>
1384         It is important to note that the barrier to <B>library</B> scope
1385         are modules marked as being self contained.  Libraries that you
1386         are import are typically self contained so you would not have 
1387         access to library-scoped elements declared in those imports nor
1388         would those imports have access to library-scoped elements that
1389         you declare.
1390     </UL>
1391     <BR><B>public</B>
1392     <UL>
1393         <P>
1394         Anyone can access this declaration if it is within the reach
1395         of a semantic search.
1396     </UL>
1397     <BR><B>lvalue</B>
1398     <UL>
1399         <P>
1400         When used with a procedure argument <B>lvalue</B> requires that 
1401         the caller supply an <I>lvalue</I> for that argument and forces
1402         the object to be passed by reference.  When applied to a procedure's
1403         return type it requires that the procedure return an lvalue and
1404         this lvalue will also be passed by reference back to the caller.
1405         <P>
1406         When used in other circumstances <B>lvalue</B> is meaningless
1407         because a declaration is, by default, an lvalue.
1408         <P>
1409         In Rune, an lvalue is specified as a scope qualifier but is actually
1410         both a scope and storage qualifier.   An lvalue type can be cast
1411         to a non-lvalue version of the same type, but not vise-versa.
1412         It should be noted that you operate on an lvalue as if it
1413         were a directly declared object.  That is, you do not need to
1414         indirect through it.  Here is an example:
1415         <P>
1416         <UL><PRE>
1417 #!usr/local/rune/bin/rune
1418 #
1419 # Program to demonstrate lvalue scope (a special kind of pass by
1420 # reference that is used in a pass-by-value manner).
1421 #
1422 import "sys" as self;
1423 import "stdio";
1424
1425 int
1426 main()
1427 {
1428     int x = 10;
1429     int y = 20;
1430     int z = 30;
1431
1432     ++increment(increment(x,y),z);
1433     stdio.stdout->show("Should be 11, 21, and 31 result is:", x, y, z);
1434 }
1435
1436 lvalue int
1437 increment(lvalue int x, lvalue int y)
1438 {
1439     ++x;
1440     return(y);
1441 }
1442         </PRE></UL>
1443         <P>
1444         As you can see, <B>lvalue</B> scope is an extremely powerful 
1445         mechanism in Rune.  It is used heavily in operator declarations
1446         and can be fully exploited by the programmer.
1447         <P>
1448     </UL>
1449     <BR><B>__nozero</B>
1450     <UL>
1451         <P>
1452         Storage is not cleaned up (zerod).  This may only be specified on
1453         objects which are not or do not contain pointers.  This allows
1454         uninitalized elements to hold garbage instead of being zerod.
1455         This qualifier is really only applicable for stack-based or
1456         heap-based storage and has no effect on global or persist storage.
1457         <P>
1458         It recommended that this feature only be used when declaring large
1459         buffers on the stack.
1460     </UL>
1461     <BR><B>global</B>
1462     <UL>
1463         <P>
1464         Specify that the declaration represents global storage.  You can
1465         embed global storage anywhere.  It can be specified in a procedure,
1466         in a class, in a compound type, and as a procedure argument.
1467         Declarations made at the top level of a source file are automatically
1468         <B>global</B> by virtue of the import itself representing global
1469         storage.
1470         <P>
1471         <B>Note that this qualifier does not effect visibility or scope.
1472         Do not confuse global with C's static/extern mechanism.</B>
1473         <P>
1474         <B>global</B> may also be applied to non-storage entities such
1475         as procedure declarations, and implies that the procedure can
1476         be called through its class directly rather then through
1477         an instantiated object.
1478         <P>
1479         While a <B>global</B> procedure can also be a method procedure,
1480         it can also access global declarations within its class
1481         directly without using <B>this</B>.  However, note that subclass
1482         refinement works differently between direct variable access and
1483         method access.  Direct variable access will get the global in
1484         the class the procedure is defined in, whether or not the procedure
1485         is being called through a subclass.  Method access using <B>this</B>,
1486         on the otherhand, will access properly refined globals found in
1487         the subclass even if the procedure is defined in the superclass,
1488         just as normal refined elements are accessed.  This can be 
1489         demonstrated with a program:
1490         <P>
1491         <UL><PRE>
1492 #!usr/local/rune/bin/rune
1493 #
1494 # Program to demonstrate the handling of a global procedure when refining
1495 # a global variable in a subclass.  Each subclass gets its own set of
1496 # globals.
1497
1498 import "sys" as self;
1499 import "stdio";
1500
1501 class fubar {
1502     public global int x = 1;
1503
1504     public global method int test()
1505     {
1506         stdio.stdout->show(x, this.x);
1507     }
1508 }
1509
1510 subclass fubar as fubar2 {
1511     refine global int x = 10;
1512 }
1513
1514 int
1515 main()
1516 {
1517     stdio.stdout->show("results should be (1 1) and (1 10)");
1518     fubar.test();
1519     fubar2.test();
1520 }
1521         </PRE></UL>
1522         <P>
1523         It is very typical to implement <B>global</B> and
1524         <B>global</B> <B>const</B> elements in classes.  These elements
1525         may be referenced via the class type or pointer, even a NULL
1526         pointer, because no object is needed to access the elements.
1527         These elements are roughly similar to how constants are defined in
1528         C using #define, but they operate within the namespace of the
1529         class so collisions aren't possible.  This frees the programmer
1530         to use more simplified naming conventions.
1531     </UL>
1532     <BR><B>persist</B>
1533     <UL>
1534         <P>
1535         Persistent storage which survives program exit and will be resurrected
1536         when the program is restarted.  Pointers do not survive and will be
1537         NULLed-out on program [re]start.  Initializers are only executed to
1538         create the initial instance of the object and will not re-execute on
1539         restart.
1540         <P>
1541         The storage is memory-mapped with mmap() using a file path based on
1542         the import path and variable name.  Flags are as follows:
1543         <P>
1544         <UL>
1545             MAP_NOSYNC|MAP_SHARED|MAP_NOCORE
1546         </UL>
1547         <P>
1548         Changing the topology or the size of the structure may break any
1549         persistent store if you are not careful.  Each named object is
1550         separately mapped so we do not recommend this flag be used on many
1551         small individual variables.  Objects may be mapped to a different
1552         location on each restart.  Also note that all void constructors
1553         will be executed on program [re]start.
1554         <P>
1555     </UL>
1556     <BR><B>heap</B>
1557     <UL>
1558         <P>
1559         The storage is not embedded but is instead dynamically allocated.
1560     </UL>
1561     <BR><B>thread</B>
1562     <UL>
1563         <P>
1564         Threaded procedure (applies to procedures only).  When a threaded
1565         procedure is called a new thread is created to run the procedure in
1566         and the calling thread is suspended.  The calling thread will be
1567         resumed with a result from the threaded procedure when the
1568         threaded procedure executes the <B>result</B> or <B>return</B>
1569         statements.  Obviously there isn't much point to threading the
1570         procedure if all it does is run to completion and call <B>return</B>.
1571         The usual scenario is for the threaded procedure to call <B>result</B>
1572         and to then continue running.
1573         <P>
1574         Note that once a threaded procedure returns a result with <B>result</B>,
1575         the return value and procedure arguments will no longer be available
1576         to it (because these are part of the original caller's context and we
1577         just resumed the original caller, so the context goes poof).  A threaded
1578         procedure must copy any arguments it wishes to access after calling
1579         <B>result</B>.
1580     </UL>
1581     <BR><B>pure</B>
1582     <UL>
1583         <P>
1584         Generally applied to operators, casts, and procedures.  If the
1585         arguments to the operator, cast, or procedure are pure or constants,
1586         then the result will also be considered pure and a constant.  That
1587         is the result will be fixed given the same arguments, allowing the
1588         operation to be optimized out entirely.
1589         <P>
1590         This flag also implies that the operator, cast, or procedure has
1591         no side effects and that it can be executed by the interpreter as
1592         a pre-stage to compilation in addition to being optimized by the
1593         interpreter.
1594         <P>
1595         Note that normal <B>const</B> variable declarations are automatically
1596         considered to be pure and do not have be scoped pure.
1597     </UL>
1598     <FONT COLOR="red">
1599     <BR><B>prototype</B>
1600     <UL>
1601         <P>
1602         This indicates that the class may NOT be directly instantiated
1603         as an object and instead may only be used as an API specification
1604         and (for a class) to provide default implementations for subclasses.
1605         Any subclasses will be realizable unless they to are specified
1606         as prototypes.
1607         Most typically this situation involves a class containing numerous
1608         generic types such as <I>Integer</I>, using a typedef, where
1609         realization makes no sense, and subclasses must refine the typedef
1610         into a subclass to specify the actual type.
1611         <P>
1612     </UL>
1613     </FONT>
1614     <BR><FONT COLOR="red"><B>async</B>
1615     <UL>
1616         <P>
1617         A threaded procedure qualified as 'async' is run as its own machine
1618         thread, truely asynchronous from the caller's context once it posts
1619         its result.  This is distinguished from the default threading mode
1620         which is always synchronous.  A synchronous thread borrows the callers
1621         context and only switches when it blocks.
1622         <P>
1623         Not all threads should be asynchronous.  For example, if implementing
1624         a GUI gadget library the potentially many gadgets can be implemented
1625         as synchronous threads instead a single asynchronous container, since
1626         only one gadget at a time is typically being manipulated.
1627         <P>
1628         This scope qualifier may only be used as part of a threaded procedure
1629         declaration.
1630     </UL></FONT>
1631     <FONT COLOR="red">
1632     <BR><B>hard</B>
1633     <UL>
1634         <P>
1635         Tells Rune that all object locks currently held upon entry into
1636         hard mode and any locks obtained while in hard mode may
1637         <I><B>NOT</B></I> be temporarily released due to the thread blocking
1638         until hard mode is exited.  It is possible to deadlock your program
1639         if you use this mode incorrectly.  Hard mode use can stack.
1640         <P>
1641         It is important to note that this also means that any locks
1642         that were obtained in prior soft modes will, during the hard
1643         mode operation, not be temporarily releaseable.  They will return
1644         to being temporarily releaseable when you exit hard mode.
1645         <P>
1646         This is important for several reasons not the least of which being
1647         that it allows Rune to use a simple index field and save/restore
1648         to govern hard/soft operation, so the overhead is effectively O(1)
1649         regardless of how many locks are currently held.
1650         <P>
1651         This mode can be applied to a whole procedure or to a specific
1652         statement or statement block.
1653     </UL>
1654     <BR><B>soft</B>
1655     <UL>
1656         <P>
1657         Tells Rune that any new object locks obtained after entry into
1658         soft mode <I><B>MAY</B></I> be temporarily released due to
1659         the thread blocking.  This is the default mode of operation.
1660         Soft mode use can stack.
1661         <P>
1662         If you were in <I>hard</I> mode and then enter <I>soft</I> mode,
1663         only new locks obtained after entering <I>soft</I> mode can be
1664         temporarily released.  More importantly, any recursive locking
1665         where the lock is already being held from <I>hard</I> mode will
1666         not cause the lock to suddenly be releaseable.  It will remain
1667         non-releaseable.
1668         <P>
1669         This mode can be applied to a whole procedure or to a specific
1670         statement or statement block.  soft-held locks cannot deadlock
1671         your application which is why Rune makes it the default operation.
1672         <P>
1673         Rune automatically locks the storage governing any objects while they
1674         are being accessed and automatically locks any object which is the
1675         target of a pointer while the pointer is active, including pointers
1676         passed as arguments (either directly or indirectly via an expression).
1677         <P>
1678         Call targets can assume that all arguments and any objects pointed
1679         to by arguments are locked.  Pointer arguments will receive an
1680         extra lock reference allowing the target procedure to drop the
1681         current lock and acquire a new lock on reassignment (this can be
1682         optimized out if the procedure does not reassign the argument).
1683         The caller is responsible for destroying the argument space and
1684         dereferencing/unlocking any non-NULL pointer arguments upon return.
1685         <P>
1686         It is important to note how Rune optimizes locking operations
1687         across blocking conditions.  Locks are on governing storage,
1688         typically on a per-dynamic-allocation basis, not on each individual
1689         object (so the size of an object is similar to what it is in C...
1690         as-expected by the programmer).  Even so, there could be many locks
1691         held when a thread blocks.  Rune handles this by leaving the locks
1692         intact and flagging the thread to allow other threads to steal the
1693         locks while it is blocked.  When it wakes up it will recover any
1694         lost locks.  This is handled optimally, so a thread could potentially
1695         have hundreds of held locks without incuring significant extra 
1696         overhead when it blocks.  Rune tracks lost/regained locks and supplies
1697         access methods to object storage to allow programs to detect if object
1698         locks were stolen across complex sections of code, or not.
1699         <P>
1700         This form of object locking is automatic and cannot be disabled
1701         by the programmer.  It is necessary for proper handling of objects
1702         and to prevent SMP races in a multi-threaded environment.
1703         <P>
1704         The default soft locks do not prevent races in application code
1705         per-say, they simply ensure that Rune doesn't corrupt itself.
1706         The programmer can make assumptions on the atomicy of multiple
1707         statements with regards to objects whos pointers are being held
1708         (verses temporarily calculated with an expression), but must
1709         recognize that dereferencing any new pointer or making a procedure
1710         call into unknown code might cause held locks to be temporarily
1711         lost.
1712         <P>
1713         Rune programmers can ensure that held locks are not lost across a
1714         set of statements by using a <B>hard</B> code section around those
1715         statements.  In fact, Rune programmers are expected to use
1716         <B>hard</B> code sections precisely for this reason for anything
1717         non-trivial.
1718         <P>
1719         Rune does NOT cache temporary object locks.  That is, it explicitly
1720         does not retain the lock past the temporary objects use.  The
1721         programmer can optimize-out unnecessary unlock/re-lock operations
1722         simply by assigning the pointer to a local pointer variable.
1723     </UL>
1724     </FONT>
1725     <BR><B>constructor</B>
1726     <UL>
1727         <P>
1728         Indicate that this procedure is also a constructor.  Constructors
1729         must take no arguments and must also be methods.  Constructors
1730         are called when an object is instantiated, after any defaults have
1731         been set.  Constructors will be called in the order in which they
1732         were declared.  Refined constructors will be called in the order
1733         in which they were defined in their superclass.  Extension 
1734         constructors in the subclass are called last.
1735         <P>
1736         WARNING! All void constructors are always called when a persistent
1737         object is restarted.  Initializers are only called on the initial
1738         creation of a persistent object.
1739     </UL>
1740     <BR><B>destructor</B>
1741     <UL>
1742         <P>
1743         Indicate that this procedure is also a destructor.  Destructors
1744         must take no arguments and must also be methods.  Destructors
1745         are called when an object looses its last reference.  For example,
1746         the stdio library will flush and close an underlying file and
1747         the graphics library will cleanup XIDs.
1748         <P>
1749         Destructors will be called in the order in which they
1750         were declared.  Refined destructors will be called in the order
1751         in which they were defined in their superclass.  Extension 
1752         destructors in the subclass are called last.
1753         <P>
1754         WARNING! Destructors are not typically called on persistent objects.
1755     </UL>
1756     <BR><B>__align(<I>simple_integer</I>)</B>
1757     <UL>
1758         <P>
1759         Force alignment of the storage to the specified number of bytes,
1760         regardless of the alignment that Rune would otherwise choose for this
1761         storage.  Alignment must be a power of 2.  This feature is used
1762         to create C-compatable prototypes and structures and is considered
1763         NONPORTABLE when used in general Rune programming.
1764         <P>
1765         <B>NOTE: Rune by definition lays out structural elements using
1766                  their natural (portable) alignment.  That is, a 64-bit
1767                  integer will be 8-byte aligned, and so forth.  Including
1768                  pointers and including larger integral and floating types.</B>
1769     </UL>
1770     <BR><B>__clang</B>
1771     <UL>
1772         <P>
1773         Force C compatibility (non-inclusive of alignment issues).  This
1774         feature is used to create C-compatible prototypes and structures
1775         and should not be used in general Rune programming.  In particular,
1776         it will force pointers to be C-compatible.  Pointers in Rune normally
1777         contain bounds and referential information along with the data
1778         pointer value.
1779         <P>
1780         <B>This feature is meant to be used only by core system support.
1781         No application should ever use it and we will likely default
1782         the resolver to disallow it outside of core system elements</B>.
1783     </UL>
1784 </UL>
1785
1786 <P>stor_qual:
1787 <UL>
1788     <BR><B>const</B>
1789     <UL>
1790         <P>
1791         Constant storage.  The object represents a constant, meaning that
1792         the object can only be initialized at the time it is instantiated
1793         and may not be changed afterwords.  Because you can override
1794         constants when you instantiate an object, constants will take up
1795         literal space in the structure unless you declare them with
1796         <B>global</B> scope.
1797     </UL>
1798
1799     <BR><B>volatile</B>
1800     <UL>
1801         <P>
1802         Normally Rune assumes that storage is semi-stable due to locking
1803         effects, depending on whether the execution context is hard or
1804         soft.  When a hard section calls a soft section Rune assumes that
1805         object locks might be lost.  If it does not, the Rune code generator
1806         is allowed to cache object data even across procedure calls if it
1807         can prove the case through analysis.
1808         <P>
1809         This storage qualifier forces Rune to assume that the contents of
1810         the storage can be modified at any time outside of Rune's control.
1811         Rune will always synchronize changes at the time they are made and
1812         will not cache the contents regardless of whether it is in a hard
1813         or soft code section.
1814     </UL>
1815 </UL>
1816
1817 <P>procedureClass:
1818 <UL>
1819     <BR><B>operator</B> string
1820     <UL>
1821         <P>
1822         An operatic procedure associates an operator with a procedure.  
1823         For example, <B>operator "++" int (lvalue int v) { ... }</B>.
1824         Operatic procedures may be unary or binary.  You can act on an
1825         lvalue or an rvalue (the default is an rvalue).  Note that lvalues
1826         require lvalue semantics and will be operated on by reference,
1827         whereas rvalues are passed by value.
1828         <P>
1829         operatic functions may be called as procedures as well as used 
1830         via their operators.  You may also use the <B>lvalue</B> qualifier
1831         for normal procedural arguments and for return values.  However,
1832         note that you may not return stack-allocated storage as an lvalue
1833         (for obvious reasons) (XXX).
1834         <P>
1835         Non-lvalue return values are stored in temporary space and thus
1836         cannot be modified by the caller.  This makes the 'const'
1837         storage qualifier redundant when applied to an operator's 
1838         return value.  Rune special-cases the use of const-qualified return
1839         values from operators to mean the following: <B>if the arguments
1840         the procedure are constants, and the procedure's return type is
1841         const-qualified, then the return value is assumed to be a constant
1842         as well and Rune is free to cache and use it, potentially resulting
1843         in the procedure never being called again.</B>
1844     </UL>
1845
1846     <BR><B>cast</B>     
1847     <UL>
1848         <P>
1849         A cast allows an object of one type to be cast to an object of
1850         another type.  The cast procedure may be defined in either object's
1851         class.
1852     </UL>
1853
1854     <BR><B>method</b>
1855     <UL>
1856         <P>
1857         A method procedure is like a normal procedure except that it
1858         can only be called through an object (or the type if this is a
1859         <B>global</B> qualified method).  The object the procedure is
1860         called through is silently passed to it as an lvalue with the
1861         identifier <B>this</B>.
1862         For example, the <I>stdio</I>
1863         library has a method call for <B>FILE</B> called <B>setMode</B> that
1864         looks like this:
1865         <UL>
1866             <P>
1867             <PRE>
1868 public class FILE {
1869     ...
1870     public method void
1871     setMode(int mode)
1872     {
1873         this.mode = mode;
1874     }
1875 }
1876             </PRE>
1877         </UL>
1878         <P>
1879         You would use the method call through a file pointer.  For example
1880         you might say <B>fi->setMode(FILE.M_FULL);</B>.  Note that
1881         <B>this</B> is not a keyword here, it is just an argument
1882         declaration that the parser quietly adds to the procedure's arguments.
1883         <P>
1884         You can also have <I>global</I> method calls.  A global method call
1885         is like a normal method call except the first argument is a type
1886         rather then the object, so you can only access global elements within
1887         the class.  Global method calls are often used to supply creation
1888         and destruction functions for objects.
1889         <P>
1890         Finally, it is possible for the programmer to override the <B>this</B>
1891         argument by explicitly declaring it as the first argument.  This is
1892         only necessary when you wish to implement a method on a pointer or
1893         reference type rather then the object being pointed to.  A good
1894         example of this is the
1895         <B>Frame.createFrame()</B> method in <B>classes/gfx/window.d</B>.
1896         The feature allows you to call a method through a NULL pointer and
1897         have the method allocate the object and assign it to the pointer. 
1898         The feature can be used for other things as well.
1899         <P>
1900         Method calls provide extremely useful shortcuts in project design.
1901     </UL>
1902
1903     <BR><B>macro</B>
1904     <UL>
1905         <P>
1906         A macro procedure is roughly equivalent to a GCC inline.  In Rune,
1907         macro procedures (and normal procedures and operators for that
1908         matter) can be coupled with <B>lvalue</B>-qualified arguments
1909         to operate directly on the variables being passed and/or returned.
1910         <FONT COLOR="red">Macro procedures are not yet implemented.</FONT>
1911     </UL>
1912
1913     <BR><I>null</I>
1914     <UL>
1915         <P>
1916         If no procedural scope is specified, a normal procedure is assumed.
1917     </UL>
1918 </UL>
1919
1920 <P>compound_exp:
1921 <UL>
1922     <BR>"(" [ [<I>id</I> ":"] <I>exp</I> ["," [<I>id</I> ":"] <I>exp</I> ]* ] ")"
1923     <UL>
1924         <P>
1925         A parenthesized expression such as <B>(1, 2)</B> is a compound
1926         expression.  Compound expressions may have several elements.
1927         <B>Note that in Rune, there is no 'comma' operator.  The operator
1928         instead denotes a compound expression occuring within parenthesis</B>.
1929         <P>
1930         A compound expression has an associated compound type (which
1931         is specified in a similar manner through comma delineation).
1932         Compound expressions are not vectorized in Rune.  That is, you
1933         cannot use an operator defined for a normal non-compound
1934         type like <B>int</B> on a compound type made up of <B>int</B>s.
1935         You can, however, define and use operators specifically designed
1936         to operate on compound expressions.
1937         <P>
1938         The elements in a compound expression may be named.  The named
1939         elements correspond with similar named elements in the associated
1940         compound type.  <B>In Rune, procedure arguments are really just a
1941         compound expression.  The ability to name procedure arguments is,
1942         in fact, nothing more then the ability to name elements in a
1943         compound expression.</B>
1944         <P>
1945         In Rune a simple parenthesized expression such as <B>(23)</B> is
1946         not usually compound.  Rune will, however, convert it to compound
1947         if it knows it has to be.  You can always force simple expressions
1948         into compound expressions by naming the element.  For example,
1949         <B>(int a = 4, int b) v = (b:23);</B> is reasonable.
1950         <P>
1951         When specifying unnamed elements in a compound expression, Rune will
1952         match your element up with an elment in the associated compound
1953         type by searching the compound type from its current position
1954         for the next non-global storage element.  <B>global and non-storage
1955         elements in a compound type are ignored unless specifically named.</B>
1956         When you specify a named element, Rune will seek it's scan position to
1957         that element and any unnamed elements occuring afterwords will also
1958         occur after that element in the compound type.  <B>Reverse seeks
1959         are allowed... that is, specifying a named element occuring before
1960         the current element.  Additionally, you can name the same element
1961         more then once, overwriting its previous contents, and you can
1962         name a global element, modifying the global storage.</B>
1963         <P>
1964         Any elements without defaults which are not initialized will be
1965         initialized to zero unless the declaration is qualified with
1966         <B>__nozero</B>.  Note that <B>__nozero</B> declarations may not
1967         be pointers and may not contain pointers.
1968         <P>
1969         Note that procedures may also return compound types.
1970         <P>
1971         As a degenerate case, <B>()</B> is equivalent to <B>void</B>.
1972     </UL>
1973 </UL>
1974
1975 <P>id:
1976 <UL>
1977     <BR>[a-z,A-Z,_]+ [a-z,A-Z,0-9,_]*
1978     <BR><B>this</B>
1979     <BR><B>self</B>
1980     <P>
1981     An identifier.  Identifiers which begin with an upper-case character
1982     are types or classes.  Identifiers which begin with a lower-case
1983     character are variables.  Identifiers which are all-caps are constants.
1984     Also, identifiers which terminate in <B>_t</B>, <B>_u</B>, <B>_p</B>, or
1985     <B>_m</B> are types or classes regardless of how they start.
1986     <P>
1987     In general, these restrictions make the code more readable and also
1988     have the important effect of allowing the parser to distinguish between
1989     expressions, types, and declarations without needing to track down what
1990     the identifier is referencing... extremely important since the parser
1991     likely can't figure out what the identifier refers to until late in
1992     the resolver.
1993     <P>
1994     There are a few exceptions: <B>void</B>, <B>bool</B>, <B>char</B>,
1995     <B>int</B>, <B>uint</B>, <B>long</B>, <B>ulong</B>, <B>float</B>,
1996     <B>double</B>, and <B>ldouble</B> are still configured in the
1997     system class library but the identifiers are allowed to be types
1998     or classes.
1999     <P>
2000     <B>NOTE: Upper-case and lower-case is defined by standard ascii,
2001              not uni-code.</B>
2002 </UL>
2003
2004 <P>constant:
2005 <UL>
2006     <BR>[ "0x" ] [0-9]+ [0-9]* [ "." <I>extension</I> ]
2007     <BR>[0-9]+ [0-9]* "." [0-9]* [ {"E"|"e"} {"+"|"-"} [0-9]+ ] [ "." <I>extension</I> ]
2008     <BR>'<I>character</I>'
2009     <P>
2010     Extensions are as follows:
2011     <UL>
2012          <P><B>B</B> - 8 bit quantity
2013         <BR><B>W</B> - 16 bit quantity
2014         <BR>(none) - 32 bit quantity (default)
2015         <BR><B>L</B> - 64 bit quantity
2016          <P><B>UB</B> - unsigned 8 bit quantity (this is the 'char' type)
2017         <BR><B>UW</B> - unsigned 16 bit quantity
2018         <BR><B>U</B> - unsigned 32 bit quantity
2019         <BR><B>UL</B> - unsigned 64 bit quantity
2020          <P><B>F</B> - float (32 bits)
2021         <BR><B>D</B> - double (64 bits) default for floating point)
2022         <BR><B>X</B> - long double (128 bits)
2023     </UL>
2024 </UL>
2025
2026 <P>string:
2027 <UL>
2028     <BR>[ '"' [<I>character-no-ctrl</I>]* '"' ]+
2029     <P>
2030     Standard double quotes enclose a string.  Rune supports ANSI string
2031     concatenation whereby several quoted strings strung together are
2032     parsed as a single string.  Control characters (0x00-0x1F) may not
2033     be directly embedded in strings and must be properly escaped.  Newlines
2034     in particular.
2035
2036 </UL>
2037
2038 <P>operator:
2039 <UL>
2040     <BR>[~!$%^&amp;*-=+|&lt;&gt;?/]+
2041     <UL>
2042         <P>
2043         Note: certain operators are reserved and may not be defined by
2044         the user.  All operators beginning with one or more '*'s are 
2045         reserved (they are used for multiple-pointer indirection).
2046         <P>
2047         Reserved operators:
2048         <UL>
2049             <P><B>=</B> - assignment
2050             <P><B>&amp;</B> - address-of
2051             <P><B>*</B> - indirect through
2052         </UL>
2053         <P>
2054         Also note that Rune does not allow user-defined or system-defined
2055         unary <I>postfix</I> operators.  Only unary <I>prefix</I> operators.
2056         Array accesses (which are post-unary) are explicitly parsed and
2057         not considered an operator for this purpose.
2058         This means, among other things, that only prefixed <B>++</B> and
2059         <B>--</B> operators are supported.
2060         <P>
2061         It's just as well, a lot of programmers can't wrap their heads
2062         around post-increment and post-decrement (or, worse, use both
2063         forms willy nilly).  More importantly, since Rune has no
2064         reverse-reference or deferred-reference limitations it must be able
2065         to definitively parse all operators at parse-time and that can't
2066         be done if we were to allow post-unary operators.
2067         <P>
2068         Finally, note that lvalue specifications are fully supported in
2069         the general syntax so you, the programmer, can implement your
2070         own lvalue-updating operators if you really want to.  Assignments,
2071         unary operators, whatever.  This is a very powerful feature of Rune.
2072     </UL>
2073 </UL>
2074
2075 <P>character:
2076 <UL>
2077     <BR><I>blah</I> - any character except backslash and whatever quote
2078                       character is enclosing this string or character
2079                       constant.
2080     <P>"\n" - a newline (ascii 10)
2081     <P>"\r" - a return (ascii 13)
2082     <P>"\t" - a tab character (ascii 9)
2083     <P>"\\" - a backslash
2084     <P>"\n[n[n]]" - an octal code with 1-3 digits
2085     <P>"\xNN" - a 8-bit hex code where NN is two hex digits.
2086     <P>
2087     NOTE: Programs which emit Rune should use the hex extension rather
2088           than the octal extension.  If the octal extension is desired,
2089           encoding all three octal digits is recommended to avoid
2090           mis-parsing normal numeric characters that might occur after
2091           the escaped character.
2092 </UL>
2093
2094 <P>specials:
2095 <UL>
2096     <P>"."
2097     <BR>":"
2098     <BR>";"
2099     <BR>","
2100     <BR>"{"
2101     <BR>"}"
2102     <BR>"["
2103     <BR>"]"
2104     <BR>"("
2105     <BR>")"
2106     <BR>"`"
2107     <BR>"="
2108     <BR>"->"
2109 </UL>
2110
2111 <P>whitespace:
2112 <UL>
2113     <P>ascii 0x09 (tab)
2114     <BR>ascii 0x0A (newline)
2115     <BR>ascii 0x0C (return)
2116     <BR>ascii 0x0D (formfeed)
2117 </UL>
2118
2119 <P>comments:
2120 <UL>
2121     <P>"#" <I>anything except newline</I> "\n"
2122     <BR>"/*" <I>anything except '*/'</I> "*/"
2123     <BR>"//" <I>anything except newline</I> "\n"
2124     <P>
2125     Rune allows all three styles but the native Rune commenting form is
2126     to use '#'.  The standard Rune coding for a comment is to leave a
2127     blank line before the comment and an empty line with just a # at the
2128     end of the comment, like this:
2129     <UL><PRE>
2130 # Hey I'm setting x to 1 here, isn't this a dumb comment?
2131 #
2132 x = 1;
2133
2134 # And b is being set to 2.  I guess I didn't learn my lesson.
2135 #
2136 b = 2;
2137     </PRE></UL>
2138     For comments occuring after an open-brace a #-only line is typically
2139     used instead of a blank line.
2140     <UL><PRE>
2141 for (i = 0; i < 10; ++i) {
2142     #
2143     # Oh this is not a good idea.
2144     #
2145     j = i;
2146     i = 1;
2147
2148     # But don't sweat it, I can fix this snafu.
2149     #
2150     i = j;
2151 }
2152     </PRE></UL>
2153     Continuity is important, particularly when commenting inside
2154     conditionals.  Using a #-only line maintains continuity when desired
2155     without crushing the comment text against the statement above or below
2156     it, which can make code (and comments) hard to read.
2157 </UL>
2158
2159 <P>Operator Precedences:
2160 <UL>
2161     <TABLE BORDER=2>
2162         <TR><TD><B>Type</B></TD><TD><B>Operator</B></TD><TD><B>Precedence</B></TD></TR>
2163         <TR><TD>binary</TD><TD>.</TD><TD>60</TD></TR>
2164         <TR><TD>binary</TD><TD>-&gt;</TD><TD>60</TD></TR>
2165         <TR><TD>binary</TD><TD><I>closure</I></TD><TD>60</TD></TR>
2166         <TR><TD>binary</TD><TD><I>call</I></TD><TD>60</TD></TR>
2167         <TR><TD>binary</TD><TD><I>user-defined</I></TD><TD>40</TD><TD>Other operators<BR>not already covered</TD></TR>
2168         <TR><TD>binary</TD><TD>+</TD><TD>35</TD><TD>Any operator containing '-' or '+'</TD></TR>
2169         <TR><TD>binary</TD><TD>-</TD><TD>35</TD></TR>
2170         <TR><TD>binary</TD><TD><I>compare</I></TD><TD>33</TD><TD>Any operator containing &lt;, =, or &gt; (overrides '-' and '+')</TD></TR>
2171         <TR><TD>binary</TD><TD>&&</TD><TD>30</TD></TR>
2172         <TR><TD>binary</TD><TD>||</TD><TD>30</TD></TR>
2173         <TR><TD>binary</TD><TD>=</TD><TD>20</TD><TD>right-to-left</TD></TR>
2174         <TR><TD>binary</TD><TD>:=</TD><TD>20</TD><TD>right-to-left</TD></TR>
2175     </TABLE>
2176     <TABLE BORDER=2>
2177         <TR><TD><B>Type</B></TD><TD><B>Operator</B></TD><TD><B>Precedence</B></TD></TR>
2178         <TR><TD>unary</TD><TD><I>user-defined</I></TD><TD>42</TD><TD>Other operators<BR>not already covered</TD></TR>
2179         <TR><TD>unary</TD><TD>&</TD><TD>42</TD></TR>
2180         <TR><TD>unary</TD><TD>?</TD><TD>42</TD></TR>
2181         <TR><TD>unary</TD><TD>*</TD><TD>42</TD></TR>
2182     </TABLE>
2183 </UL>
2184
2185 </BODY>
2186 </HTML>