cvsuser 03/02/16 13:23:26
Modified: languages/perl6/doc overview.pod
Log:
Fix typos and POD
Revision Changes Path
1.2 +57 -50 parrot/languages/perl6/doc/overview.pod
Index: overview.pod
===================================================================
RCS file: /cvs/public/parrot/languages/perl6/doc/overview.pod,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -w -r1.1 -r1.2
--- overview.pod 27 Sep 2002 02:18:50 -0000 1.1
+++ overview.pod 16 Feb 2003 21:23:25 -0000 1.2
@@ -9,52 +9,51 @@
=head2 Objects
-There are 3 main types of objects that are used in P6C; its best to become familiar
-with them before anything else:
+There are 3 main types of objects that are used in P6C; it's best to
+become familiar with them before anything else:
=over 3
=item B<Raw Parse Object>
Raw parse objects are generated by Parse::RecDescent when it uses the grammar
-found in P6C/Parser.pm. They contain the raw data from the parse. After the
-parse, these objects process themselves using their C<tree> methods, defined in
-P6C/Tree.pm
-
+found in F<P6C/Parser.pm>. They contain the raw data from the parse. After
+the parse, these objects process themselves using their C<tree> methods,
+defined in F<P6C/Tree.pm>.
=item B<Node Object>
-Nodes are processed Parser objects, and are defined in P6C/Nodes.pm. A tree of
-these objects is called an op tree. This tree is used in generating IMC code
-with P6C/IMCC.pm. Names mostly correspond to the rulenames from the grammar, but
-not entirely. Some are omitted, and two -- ValueList and Register -- are
-added.
-
+Nodes are processed Parser objects, and are defined in F<P6C/Nodes.pm>. A
+tree of these objects is called an op tree. This tree is used in generating
+IMC code with F<P6C/IMCC.pm>. Names mostly correspond to the rulenames from
+the grammar, but not entirely. Some are omitted, and two -- ValueList and
+Register -- are added.
=item B<Context Object>
-Context objects are defined in P6C/Context.pm, and are actually a data member
-of Node objects (although they are added during the context propagation phase,
-rather that the parse tree deciphering phase.) Context objects contain the
-current context information of the associated node.
+Context objects are defined in F<P6C/Context.pm>, and are actually a data
+member of Node objects (although they are added during the context
+propagation phase, rather that the parse tree deciphering phase.) Context
+objects contain the current context information of the associated node.
=back
=head2 Flow Control
As a brief overview, the whole process works like this: First, perl6 code is
-parsed using P6C/Parser.pm, which generates a raw parse tree. The raw tree is
-then processed by methods found in P6C/Tree.pm, turning the raw parse objects
-into an optree. Context is propagated onto the optree with P6C/Context.pm, and
-then evaluated and compiled to intermediate code by C<imcc>. C<imcc> then
-translates...this into parrot assembly code, which is then assembled into
-bytecode by the parrot assembler and run. Its just that simple.
+parsed using F<P6C/Parser.pm>, which generates a raw parse tree. The raw tree
+is then processed by methods found in F<P6C/Tree.pm>, turning the raw parse
+objects into an optree. Context is propagated onto the optree with
+F<P6C/Context.pm>, and then evaluated and compiled to intermediate code by
+C<imcc>. C<imcc> then translates...this into parrot assembly code, which is
+then assembled into bytecode by the parrot assembler and run. It's just that
+simple.
=head2 In more detail
The first thing perl6 will do is start the first pass over your code: parse it.
Assuming a normal run (no flags), perl6 will use the precompiled parser,
-Perl6Grammar.pm If you made any changes to the grammar in P6C/Parser.pm,
+F<Perl6Grammar.pm>. If you made any changes to the grammar in F<P6C/Parser.pm>,
you'll need to run your code with the --force-grammar flag to recompile it.
=head2 The Parser
@@ -99,35 +98,40 @@
varname => 'y'
Each node on this tree is actually an object in the form of a blessed
-anyonomous array, created as a result of the grammar's autoaction. It holds
+anonymous array, created as a result of the grammar's autoaction. It holds
the raw data from the parse; one element per production.
Next, on to the grammar. As stated earlier, the grammar is written in
Parse::RecDescent. For almost all cases, rules should be written without an
action as the final production, so that the autoaction that turns the match
-into an object can be applied. To get a real idea of whats going on, you
-should read through the grammar; its long, but most rules are short. The base
-rule for the grammar is C<prog>; but you can probably start at C<stmt> unless
-you care about error handling and such like that. A few notes about the
-grammar in general:
+into an object can be applied. To get a real idea of what's going on, you
+should read through the grammar; it's long, but most rules are short. The base
+rule for the grammar is C<prog>, but you can probably start at C<stmt> unless
+you care about error handling and such like that.
+
+A few notes about the grammar in general:
=over 3
=item B<"Want" Rules>
-Keywords and prefix operators use special "want_for" rules to match their correct
-definition. This is for modularity purposes. The prefix rule will match a
-keyword, and then do a hash lookup to find its corresponding "want_for" rule.
-For instance, if the "grep" keyword is found, then the lookup will then attempt
-to match the "want_for_grep" rule. The "want_for" rules match the "body" of
-the corresponding rule. Many builtin functions and unary operators will
-need their own individual "want_rule" for the parser to be accurate.
+
+Keywords and prefix operators use special "want_for" rules to match their
+correct definition. This is for modularity purposes. The prefix rule will
+match a keyword, and then do a hash lookup to find its corresponding
+"want_for" rule. For instance, if the "grep" keyword is found, then the
+lookup will then attempt to match the "want_for_grep" rule. The "want_for"
+rules match the "body" of the corresponding rule. Many builtin functions
+and unary operators will need their own individual "want_rule" for the parser
+to be accurate.
=item B<Regex as Speed Optimizations>
+
Simple rules have been redefined as compiled regular expressions for speed
purposes. These include all of the binary operators, as well as the numerical
constant, error flusher, and special string delimiter.
=item B<Special Parser Functions>
+
A few notes about some of the functions in the parser: C<add_class> adds
user-defined classes to the parser, and C<add_function> does the same for
functions. C<add_context> is used by C<add_function> to create the resulting
@@ -149,17 +153,20 @@
=over 3
=item B<Remove junk data from the raw object>
+
Removing junk amounts to removing the syntax that won't really matter to the
compiler. For instance: removing the "," from argument lists, removing special
-quote delimeters, or ignoring unnecessary whitespace. None of this syntax
+quote delimiters, or ignoring unnecessary whitespace. None of this syntax
really matters internally, so it is thrown away.
=item B<Turn the data into a processed node for "base" types>
+
If the object is a "base" type (i.e has a corresponding node type in
-P6C/Nodes.pm), the proper information is extracted from the parse object and
+F<P6C/Nodes.pm>), the proper information is extracted from the parse object and
used to create and return a new node of that type.
=item B<Otherwise, call tree on the remaining sub-objects>
+
Calls the C<tree> methods of its members, gathers up the return values, and
builds a branch of the optree.
@@ -168,13 +175,13 @@
=head2 Propagating Context
Propagating Context is another way of saying "Figuring out what kind of value a
-node is expected to yield during compilition." Context information is added to
+node is expected to yield during compilation." Context information is added to
a node by adding another member, C<ctx>, to the node, and setting its value
-equal to a context object. Context objects are defined in P6C/Context.pm,
-which also contains the functions for figuring out context. P6C/Addcontext.pm
-defines the C<ctx_left> and <ctx_right> methods for each Node type (which
-deal for lvalue and rvalue context, respectively), which define how each Node
-type propagates its context.
+equal to a context object. Context objects are defined in F<P6C/Context.pm>,
+which also contains the functions for figuring out context.
+F<P6C/Addcontext.pm> defines the C<ctx_left> and <ctx_right> methods for
+each Node type (which deal for lvalue and rvalue context, respectively),
+which define how each Node type propagates its context.
=head2 Compiling to IMC
@@ -199,7 +206,7 @@
The compiler maintains a "current function" in which code is emitted, locals
are declared, and symbol lookups begin. C<P6C/IMCC.pm::code($x)> will add the
-IMC code $x to the current function. Scope can futher be manipulated "inside"
+IMC code $x to the current function. Scope can further be manipulated "inside"
a function by using C<push_scope>, which increases the depth of the scope by
one, and C<pop_scope>, which lowers it by one.
@@ -216,21 +223,21 @@
=item B<code generation>
There are many functions that aid in the generation of IMC code; see the
-P6C/IMCC.pm documentation for more details.
+F<P6C/IMCC.pm> documentation for more details.
=back
=head2 Finishing the process
From this point on, most of the work is done by external parrot processes.
-First, P6C/IMCC.pm is used to convert the op tree to .imc code. IMCC converts
-this code to .pasm. The assembler assembles the the .pasm to parrot bytecode,
-and then finally the bytecode is run by the driver.
+First, F<P6C/IMCC.pm> is used to convert the op tree to .imc code. IMCC
+converts this code to .pasm. The assembler assembles the the .pasm to
+parrot bytecode, and then finally the bytecode is run by the driver.
=head2 Author of this document
Joseph F. Ryan ([EMAIL PROTECTED])
-$Id: overview.pod,v 1.1 2002/09/27 02:18:50 educated_foo Exp $
+$Id: overview.pod,v 1.2 2003/02/16 21:23:25 scog Exp $
=cut
