Pod6 is an easy-to-use markup language. It can be used for writing language documentation, for documenting programs and modules, as well as for other types of document composition.
Every Pod6 document has to begin with
=begin pod and end with
=end pod. Everything between these two delimiters will be processed and used to generate documentation.
=begin podA very simple Pod6 document=end pod
A Pod6 document may consist of multiple Pod6 blocks. There are four ways to define a block: delimited, paragraph, abbreviated, and declarator; the first three yield the same result but the fourth differs. You can use whichever form is most convenient for your particular documentation task.
Delimited blocks are bounded by
=end markers, both of which are followed by a valid Raku identifier, which is the
typename of the block. Typenames that are entirely lowercase (for example:
=begin head1) or entirely uppercase (for example:
=begin SYNOPSIS) are reserved. Indentation of the =begin/=end lines is required to be the same to create a valid block; otherwise, an error or unexpected results will occur.
=begin head1Top Level Heading=end head1
After the typename, the rest of the
=begin marker line is treated as configuration information for the block. This information is used in different ways by different types of blocks, but is always specified using Raku-ish option pairs. That is, any of:
|Value is...||Specify with...||Or with...||Or with...|
|List||:key[$e1, $e2, ...]||:key($e1, $e2, ...)||:key<$e1 $e2 ...>|
Where '$e1, $e2, ...' are list elements of type String, Int, Number, or Boolean. Lists may have mixed element types. Note that one-element lists are converted to the type of their element (String, Int, Number, or Boolean). Also note that big integers can be used if required.
For hashes, '$k1, $k2, ...' are keys of type Str and '$v1, $v2, ...' are values of type String, Int, Number, or Boolean.
Strings are delimited by single or double quotes. Whitespace is not significant outside of strings. Hash keys need not be quote-delimited unless they contain significant whitespace. Strings entered inside angle brackets become lists if any whitespace is used inside the angle brackets.
All option keys and values must be constants since Pod6 is a specification language, not a programming language. Specifically, option values cannot be closures. See Synopsis 2 for details of the various Raku pair notations.
The configuration section may be extended over subsequent lines. Each subsequent line must start with an
= in the first virtual column, meaning that it must vertically align with the
= of the Pod6 Block declaration, and it must be followed by at least one horizontal whitespace character.
=for head1 :a-first-line-key<firstvalue> :another-first-line-key<xyz>= :a-second-line-key(42)= :a-third-line-key<third>Content for the header block
Some of these options have a predetermined value; specifically,
:numbered is used to specify that the block item or lines will be numbered.
=for defn :numberedWeNeedNumberssay .config<numbered>; # OUTPUT: «True␤»
This configuration option can be abbreviated by a hash mark
=para #WeNeedNumberssay .config<numbered>; # OUTPUT: «1␤»
Paragraph blocks begin by a
=for marker and end by the next Pod6 directive or the first blank line. The
=for marker is followed by the
typename of the block plus, optionally, any configuration data as in the delimited blocks described above.
=for head1Top Level Heading
Abbreviated blocks begin by an
'=' sign, which is followed immediately by the
typename of the block. All following data are part of the contents of the block, thus configuration data cannot be specified for an abbreviated block. The block ends at the next Pod6 directive or the first blank line.
=head1 Top level heading
Declarator blocks differ from the others by not having a specific type, instead they are attached to some source code.
Declarator blocks are introduced by a special comment: either
#=, which must be immediately followed by either a space or an opening curly brace. If followed by a space, the block is terminated by the end of line; if followed by one or more opening curly braces, the block is terminated by the matching sequence of closing curly braces.
Blocks starting with
#| are attached to the code after them, and blocks starting with
#= are attached to the code before them.
Since declarator blocks are attached to source code, they can be used to document classes, roles, subroutines and in general any statement or block.
WHY method can be used on these classes, roles, subroutines etc. to return the attached Pod6 value.
sub duel(Magician , Magician )say Magician.WHY; # OUTPUT: «Base class for magicians␤»say .WHY.leading; # OUTPUT: «Fight mechanics␤»say .WHY.trailing; # OUTPUT: «Magicians only, no mortals.␤»
These declarations can extend multiple blocks:
* Numbers turn into strings* Regexes operate on said strings* C<with> topicalizes and places result into)sub search-in-seq( Int , Int )* topic* decont operator»
By using a matched pair of parenthesis constructs such as
«» the comments can extend multiple lines. This format will not normally translate to a multi-line display by
raku --doc. However, since Rakudo version 2020.01, there is a method to accomplish that, for leading declarator blocks only, by defining a special environment variable:
RAKUDO_POD_DECL_BLOCK_USER_FORMAT. When that value is set, running
raku with the
--doc option should show text from leading declarator blocks in its original format. See the test for the capability in the file S26-documentation/block-leading-user-format.t.
Pod6 offers a wide range of standard block types.
Headings can be defined using
=headN, where N is greater than zero (e.g.,
=head1 A top level heading=head2 A second level heading=head3 A third level heading
An ordinary paragraph consists of text that is to be formatted into a document at the current level of nesting, with whitespace squeezed, lines filled, and any special inline mark-up applied.
Ordinary paragraphs consist of one or more consecutive lines of text, each of which starts with a non-whitespace character. The paragraph is terminated by the first blank line or block directive.
=head1 This is a heading blockThis is an ordinary paragraph.Its text will be squeezed andshort lines filled. It is terminated bythe first blank line.This is another ordinary paragraph.Its text will also be squeezed andshort lines filled. It is terminated bythe trailing directive on the next line.=head2 This is another heading blockThis is yet another ordinary paragraph,at the first virtual column set by theprevious directive
Ordinary paragraphs do not require an explicit marker or delimiters.
Alternatively, there is also an explicit
=para marker that can be used to explicitly mark a paragraph.
=paraThis is an ordinary paragraph.Its text will be squeezed andshort lines filled.
In addition, the longer
=begin para and
=end para form can be used.
=begin paraThis is an ordinary paragraph.Its text will be squeezed andshort lines filled.This is still part of the same paragraph,which continues until an...=end para
As demonstrated by the previous example, within a delimited
=begin para and
=end para block, any blank lines are preserved.
Code blocks are used to specify source code, which should be rendered without re-justification, without whitespace-squeezing, and without recognizing any inline formatting codes. Typically these blocks are used to show examples of code, mark-up, or other textual specifications, and are rendered using a fixed-width font.
A code block may be implicitly specified as one or more lines of text, each of which starts with a whitespace character. The implicit code block is then terminated by a blank line.
This ordinary paragraph introduces a code block:my = 'John Doe';say ;
Code blocks can also be explicitly defined by enclosing them in
=begin code and
=begin codemy $name = 'John Doe';say $name;=end code
Pod6 provides blocks for specifying the input and output of programs.
=input block is used to specify pre-formatted keyboard input, which should be rendered without re-justification or squeezing of whitespace.
=output block is used to specify pre-formatted terminal or file output, which should also be rendered without re-justification or whitespace-squeezing.
Lists in Pod6 are specified as a series of
The three suspects are:=item Happy=item Sleepy=item Grumpy
The three suspects are:
Lists that define terms or commands use
=defn, equivalent to the
DL lists in HTML
=defn HappyWhen you're not blue.=defn BlueWhen you're not happy.
will be rendered as
- When you're not blue.
- When you're not happy.
Lists may be multi-level, with items at each level specified using the
=item3, etc. blocks.
=item is just an abbreviation for
=item1 Animal=item2 Vertebrate=item2 Invertebrate=item1 Phase=item2 Solid=item2 Liquid=item2 Gas
Using the delimited form of the
=item block (
=begin item and
=end item), we can specify items that contain multiple paragraphs.
Let's consider two common proverbs:=begin itemThis is a common myth and an unconscionable slur on the Spanishpeople, the majority of whom are extremely attractive.=end item=begin itemIn deciding whether to become an early riser, it is worthconsidering whether you would actually enjoy annelidsfor breakfast.=end itemAs you can see, folk wisdom is often of dubious value.
Let's consider two common proverbs:
The rain in Spain falls mainly on the plain.
This is a common myth and an unconscionable slur on the Spanish people, the majority of whom are extremely attractive.
The early bird gets the worm.
In deciding whether to become an early riser, it is worth considering whether you would actually enjoy annelids for breakfast.
As you can see, folk wisdom is often of dubious value.
Check out this page for documentation related to Tables
Pod6 comments are comments that Pod6 renderers ignore.
Comments are useful for metadocumentation (documenting the documentation). Single-line comments use the
=comment Add more here about the algorithm
For multi-line comments, use a delimited
=begin commentThis comment ismulti-line.=end comment
All uppercase block typenames are reserved for specifying standard documentation, publishing, source components, or metainformation.
Formatting codes provide a way to add inline mark-up to a piece of text.
All Pod6 formatting codes consist of a single capital letter followed immediately by a set of single or double angle brackets; Unicode double angle brackets may be used.
Formatting codes may nest other formatting codes.
The following codes are available: B, C, E, I, K, L, N, P, R, T, U, V, X, and Z.
To format a text in bold enclose it in
Raku is B<awesome>
Raku is awesome
To format a text in italic enclose it in
Raku is I<awesome>
Raku is awesome
To underline a text enclose it in
Raku is U<awesome>
To flag text as code and treat it verbatim enclose it in
C<my $var = 1; say $var;>
my $var = 1; say $var;
To create a link enclose it in
A vertical bar (optional) separates label and target.
The target location can be an URL (first example) or a local Pod6 document (second example). Local file names are relative to the base of the project, not the current document.
Raku homepage L<https://raku.org>L<Raku homepage|https://raku.org>
Raku homepage https://raku.org
To create a link to a section in the same document:
Alongside the normal way of describing a path, viz.
L<Some reference|path/to/filename>, it is also possible to use the module-style notation, e.g.,
This code is not implemented in
Pod::To::HTML, but is partially implemented in
A second kind of link — the
P<> or placement link — works in the opposite direction. Instead of directing focus out to another document, it allows you to assimilate the contents of another document into your own.
In other words, the
P<> formatting code takes a URI and (where possible) inserts the contents of the corresponding document inline in place of the code itself.
P<> codes are handy for breaking out standard elements of your documentation set into reusable components that can then be incorporated directly into multiple documents. For example:
If a renderer cannot find or access the external data source for a placement link, it must issue a warning and render the URI directly in some form, possibly as an outwards link. For example:
You can use any of the following URI forms (see #Links) in a placement link.
A comment is text that is never rendered.
To create a comment enclose it in
Raku is awesome Z<Of course it is!>
Raku is awesome
Notes are rendered as footnotes.
To create a note enclose it in
Raku is multi-paradigmatic N<Supporting Procedural, Object Oriented, and Functional programming>
To flag text as keyboard input enclose it in
Enter your name K<John Doe>
R<> formatting code specifies that the contained text is a replaceable item, a placeholder, or a metasyntactic variable. It is used to indicate a component of a syntax or specification that should eventually be replaced by an actual value. For example:
The basic C<ln> command is: C<ln> R<source_file> R<target_file>
Then enter your details at the prompt:=for inputName:ID:Pass:
To flag text as terminal output enclose it in
Hello T<John Doe>
To include Unicode code points or HTML5 character references in a Pod6 document, enclose them in
E< > can enclose a number, which is treated as the decimal Unicode value for the desired code point. It can also enclose explicit binary, octal, decimal, or hexadecimal numbers using the Raku notations for explicitly based numbers.
Raku makes considerable use of the E<171> and E<187> characters.Raku makes considerable use of the E<laquo> and E<raquo> characters.Raku makes considerable use of the E<0b10101011> and E<0b10111011> characters.Raku makes considerable use of the E<0o253> and E<0o273> characters.Raku makes considerable use of the E<0d171> and E<0d187> characters.Raku makes considerable use of the E<0xAB> and E<0xBB> characters.
Raku makes considerable use of the « and » characters.
This code is not implemented by
Pod::To::HTML, but is implemented in
V<> formatting code treats its entire contents as being verbatim, disregarding every apparent formatting code within it. For example:
The B<V< V<> >> formatting code disarms other codessuch as V< I<>, C<>, B<>, and M<> >.
Note, however that the
V<> code only changes the way its contents are parsed, not the way they are rendered. That is, the contents are still wrapped and formatted like plain text, and the effects of any formatting codes surrounding the
V<> code are still applied to its contents. For example the previous example is rendered as:
Anything enclosed in an
X<> code is an index entry. The contents of the code are both formatted into the document and used as the (case-insensitive) index entry:
An <strong>X<array></strong> is an ordered list of scalars indexed by number,starting with 0. A <strong>X<hash></strong> is an unordered collection of scalarvalues indexed by their associated string key.
You can specify an index entry in which the indexed text and the index entry are different, by separating the two with a vertical bar:
An <strong>X<array|arrays></strong> is an ordered list of scalars indexed by number,starting with 0. A <strong>X<hash|hashes></strong> is an unordered collection ofscalar values indexed by their associated string key.
In the two-part form, the index entry comes after the bar and is case-sensitive.
You can specify hierarchical index entries by separating indexing levels with commas:
An X<array|<strong>arrays, definition of</strong>> is an ordered list of scalarsindexed by number, starting with 0. A X<hash|<strong>hashes, definition of</strong>>is an unordered collection of scalar values indexed by theirassociated string key.
You can specify two or more entries for a single indexed text, by separating the entries with semicolons:
A X<hash|<strong>hashes, definition of; associative arrays</strong>>is an unordered collection of scalar values indexed by theirassociated string key.
The indexed text can be empty, creating a "zero-width" index entry:
<strong>X<|puns, deliberate></strong>This is called the "Orcish Maneuver"because you "OR" the "cache".
In order to generate HTML from Pod, you need the Pod::To::HTML module.
If it is not already installed, install it by running the following command:
zef install Pod::To::HTML
Once installed, run the following command in the terminal:
raku --doc=HTML input.rakudoc > output.html
In order to generate Markdown from Pod, you need the Pod::To::Markdown module.
If it is not already installed, install it by running the following command:
zef install Pod::To::Markdown
Once installed, run the following command in the terminal:
raku --doc=Markdown input.rakudoc > output.md
In order to generate text from Pod, you can use the default
Using the terminal, run the following command:
raku --doc=Text input.rakudoc > output.txt
You can omit the
raku --doc input.rakudoc > output.txt
You can even embed Pod6 directly in your program and add the traditional Unix command line "--man" option to your program with a multi MAIN subroutine like this:
multi MAIN(Bool :)
myprogram --man will output your Pod6 rendered as a man page.
In order to access Pod6 documentation from within a Raku program the special
= twigil, as documented in the variables section, must be used.
= twigil provides the introspection over the Pod6 structure, providing a Pod::Block tree root from which it is possible to access the whole structure of the Pod6 document.
As an example, the following piece of code introspects its own Pod6 documentation:
=begin pod=head1 This is a head1 titleThis is a paragraph.=head2 SubsectionHere some text for the subsection.=end podfor ->
producing the following output:
Pod::Heading.new(level => 1, config => , contents => [Pod::Block::Para.new(config => , contents => ["This is a head1 title"])]);Pod::Block::Para.new(config => , contents => ["This is a paragraph."]);Pod::Heading.new(level => 2, config => , contents => [Pod::Block::Para.new(config => , contents => ["Subsection"])]);Pod::Block::Para.new(config => , contents => ["Here some text for the subsection."]);