If you've discovered something amazing about Perl that you just need to share with everyone, this is the right place.

This section is also used for non-question discussions about Perl, and for any discussions that are not specifically programming related. For example, if you want to share or discuss opinions on hacker culture, the job market, or Perl 6 development, this is the place. (Note, however, that discussions about the PerlMonks web site belong in PerlMonks Discussion.)

Meditations is sometimes used as a sounding-board — a place to post initial drafts of perl tutorials, code modules, book reviews, articles, quizzes, etc. — so that the author can benefit from the collective insight of the monks before publishing the finished item to its proper place (be it Tutorials, Cool Uses for Perl, Reviews, or whatever). If you do this, it is generally considered appropriate to prefix your node title with "RFC:" (for "request for comments").

User Meditations
Multi-stage flip-flop?
7 direct replies — Read more / Contribute
by RonW
on Dec 10, 2014 at 18:30
    In a response to a SOPW post, I wrote:
    while (<>) { if (/^#ERRORS/ .. /^CELLS/) { push(@errors, $_); } elsif (/^CELLS/ .. /^\s*$/) { push(@errors, $_); } else { ...; # other processing } }

    Which doesn't work.

    Occurs to me that it might be a useful enhancement to allow .. conditionX to be an additional stage to the preceding condition1 .. condition2, creating a linked cascade of flip-flops:

    if (/match1/ .. /match2/) { doStage1(); } elsif (.. /match3/) { doStage2(); } elsif (.. /match4/) { doStage3(); } else { doOtherProcessing(); }

    The semantics would be an extension of .. In the second example, match1 would trigger stage 1 (doStage1() will be called). Then match2 will end stage 1 and trigger stage 2 (doStage2() will be called). Then match3 ends stage 2 and triggers stage 3 (doStage3() will be called). Finally, match4 resets the cascade.


    Updated to mention the first example doesn't work.

    Updated second example and the description of the semmantics.

Would you suggest alternative names for Perl 6?
12 direct replies — Read more / Contribute
by rsFalse
on Dec 05, 2014 at 11:00
    I was upset when I knew that Perl 6 is a different language and not compatible with Perl and have the similar name, and appeared after Perl v5. Its is messy; practically humans think that number which goes after the name means version or something like that.
    I think that a name for that new language could have to match /^Perl\s?\D.*$/i or /^\w+\sPerl$/i, but not /^Perl\s?\d+$/i.
    Maybe it could be something like "Perlix", "Perlox", "Perl*". I liked Perlox or Perlex, where maybe -ex could mean 'extended', and -ox could mean that it has optimized (o) regexes (say DFA on simple search pattern), and it doesn't count spaces in regex by default (x).
    Now it is like forbidden for Perl v1..5 to have v6.

    UPD. Sorry for mis-searching. And thanks for very nice nodes, especially very funny very first!
Gaps in the Maps of pm.orgs
5 direct replies — Read more / Contribute
by wjw
on Nov 29, 2014 at 11:37

    I recently graduated to a situation where I might have time to explore Perl in a more 'social' context: by that I mean in meat-space. To my mild consternation, a look at the map of North American Perl Monger groups only to find that I am on the eastern edge of the great northern void.

    There are a couple of these desolate areas represented on the map, Some of these are perhaps more easily explained away than others I suppose. States with lower population densities or fewer urban areas are somewhat understandable as geographical deserts of Perl desolation. However, to my way of thinking, that does not explain all of these holes in the map of North America.

    Looking at the world map is even more strange to me. Perl is such a friendly, though quirky sort of language. It seems like it would bring people together more readily....

    One area in particular is odd to me, and the source of my mild regret. I currently reside on the Northwest corner of the Minneapolis/St. Paul area of Minnesota. This is not a massive or dense urban area, but it is not small either. There are numerous higher education institutions, a broad variety of industries are represented in the region, and yet no pm group. One would think that combined with the previously mentioned advantages, the winters we have here, would lend it to be an ideal place to attract a good number of Perl users interested in jaw-jacking over a beer or two. Come to think of it, there are some pretty good beers available here too....another reason which would support congregating on occasion.

    Apparently not.

    Searches on various engines indicate there have been efforts to establish such a group to no effect over the years. Once again, I find myself grateful for this site. I guess for now, my contact with the world of Perl will continue to be ethereal... . Not complaining, just saying... .

    PS. If someone knows of something my quick search missed, please do let me know. I could use a beer....

    Update:Thanks to those of you that responded. I am looking into opensource/linux and sundry tangential subjects in the area to see what might be leveraged. I do appreciate the encouragement, though I do want to investigate the reasons that it has not been done successfully previously first before I tackle something like this. Doing it poorly would probably be more damaging than not doing it at all...

    ...the majority is always wrong, and always the last to know about it...

    A solution is nothing more than a clearly stated problem...

Opinion: where Perl5 wasn't attractive for me
14 direct replies — Read more / Contribute
by rsFalse
on Nov 19, 2014 at 05:59
    As a newbie, I was dissapointed of:
    1) Perl does not have integer division operator. It must call "use/no integer" to change type. Python has: / - normal division, // - integer division. Sugar.
    To use things such as "ceil/floor", I need to "use POSIX"... Aren't they basic?
    2) It is not problem for me to read dollars in single variables. But it is annoying to read them in some-dimensional arrays (it's noisy), e.g. $array[$i][$j] > $array[$i][$j-1].
    3) It is strongly recommended to "use strict" and make variables "my", then why it is not default? Whay all the code must have so much my my my my...?
    4) Doesn't work - "$_ = reverse"; If in subroutine I can write "$_ = shift", why can't I write so in main (I need to write "$_ = shift @_").
    5) It was strange that "cho(m)p" returns last symbol, not a string w/o last symbol. Ruby's cho(m)p I like more, because I can proceed on string: gets.cho(m)p.split.do_smth...
    6) Can't use blocks using "and/or":
    "$i > 5 or {print "No"; last}" (overcome - "$i > 5 or (print "No"), last"; comma is tighter than "or" but it is counter-intuitive for me)
    7) It was suprise for me that when I used "$hash{length}" it interpreted (length $_) as "length"; Surprise was that ++ has magic (I need to know exceptions) and -- has not; Surprise that "use bigint" doesn't DWIM in some cases.
    8) Difficult exception is that "print (1+1)*2" != "print 2*(1+1)" == "print STDOUT (1+1)*2". I think "print(..." should better wait until the end of block or ";".
Sub signatures, and a vexing parse
2 direct replies — Read more / Contribute
by davido
on Nov 18, 2014 at 16:53

    I was experimenting with the experimental subroutine signatures feature of Perl 5.20 today along with the much maligned prototypes feature of old, and encountered a most vexing parse that interested me. So I wanted to mention it here.

    First, something that is not a problem:

    *mysub = sub : prototype(\@\@) ($left,$right) { ... };

    This parses correctly, and will generate a subroutine named mysub with a prototype of \@\@, and with named parameters of $left and $right, which when called will contain array refs. But this doesn't do much. My real goal was generating several similar subroutines, and called upon map in a BEGIN{ ... } block to do the heavy lifting.

    Here is a contrived example that isn't terribly useful, but that works, and demonstrates the issue:

    use strict; use warnings; no warnings 'experimental::signatures'; use feature qw/say signatures/; use List::Util qw(all); BEGIN { ( *array_numeq,*array_streq ) = map { my $compare = $_; sub :prototype(\@\@) ($l,$r) { @$l == @$r && all { $compare->($l->[$_],$r->[$_]) } 0 .. $#$l } } sub { shift == shift }, sub { shift eq shift } } my @left = ( 1, 2, 3 ); my @right = ( 1, 2, 3 ); { local $" = ','; say "(@left) ", ( array_numeq @left, @right ) ? "matches" : "doesn't match", " (@right)"; }

    Do you see what the problem is? The compiler doesn't care for this at all, and will throw a pretty useless compiletime error:

    Array found where operator expected at mytest2.pl line 14, at end of l +ine (Missing operator before ?) syntax error at mytest2.pl line 14, near "@\@) " Global symbol "$l" requires explicit package name at mytest2.pl line 1 +4. Global symbol "$r" requires explicit package name at mytest2.pl line 1 +4. Global symbol "$l" requires explicit package name at mytest2.pl line 1 +5. Global symbol "$r" requires explicit package name at mytest2.pl line 1 +5. Global symbol "$l" requires explicit package name at mytest2.pl line 1 +6. Global symbol "$r" requires explicit package name at mytest2.pl line 1 +6. Global symbol "$l" requires explicit package name at mytest2.pl line 1 +7. BEGIN not safe after errors--compilation aborted at mytest2.pl line 17 +.

    Q: So what changed between the first example, that works, and the second example, that doesn't?

    A: Lacking other cues, the compiler parses  sub : as a label named sub, and thinks that I'm trying to call a subroutine named prototype... and from that point on things are totally out of whack.

    Solution: +. Anything that can remind the parser that it's not looking at a label will do the trick. Parenthesis around the sub : ... construct works, but + is easier, and probably more familiar to programmers who use + to get {....} to be treated as an anonymous hash ref constructor rather than as a lexical block.

    With that in mind, here's code that works:

    use strict; use warnings; no warnings 'experimental::signatures'; use feature qw/say signatures/; use List::Util qw(all); BEGIN { ( *array_numeq,*array_streq ) = map { my $compare = $_; + sub :prototype(\@\@) ($l,$r) { @$l == @$r && all { $compare->($l->[$_],$r->[$_]) } 0 .. $#$l } } sub { shift == shift }, sub { shift eq shift } } my @left = ( 1, 2, 3 ); my @right = ( 1, 2, 3 ); { local $" = ','; say "(@left) ", ( array_numeq @left, @right ) ? "matches" : "doesn't match", " (@right)"; }

    ...or how a single keystroke de-vexed the parse.

    A really simple example that breaks is this:

    my $subref = do{ sub : prototype($) ($s) { return $s; }; # Perl thinks sub: is a lab +el here. };

    I don't really see any way around the parsing confusion in the original version that doesn't work. That perl considers sub : to be a label in the absence of other cues is probably not something that can be fixed without making sub an illegal label. But if I were to file a bug report (which I haven't done yet), it would probably be related to the useless error message.

    This example is fairly contrived, but it's not impossible to think that subs with signatures and prototypes might be generated in some similar way as to fall prey to this mis-parse.

    Credit to mst and mauke on irc.perl.org#perl for deciphering why the compiler fails to DWIW.


The First Ten Perl Monks
6 direct replies — Read more / Contribute
by eyepopslikeamosquito
on Nov 16, 2014 at 08:31
The future of Perl?
26 direct replies — Read more / Contribute
by BrowserUk
on Nov 03, 2014 at 23:03

    Does it have one? Discuss.

    I express no opinion, because I'm not looking for an argument. No prompts, cribs or alternatives; because I don't want to influence what if any discussion ensues, one way or the other.

    I'm seeking, if not a consensus; then at least a census. A (possibly anonymous) expression of opinion from as many people who feel that they have a) a vested interest; b) an opinion worth expressing.

    No counter arguments; no condemnations; though I might have follow-up questions; which you are of course, perfectly entitled to ignore.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
RFC: MooX::Role::Reconstruct (was MooX::Restore)
1 direct reply — Read more / Contribute
by boftx
on Nov 03, 2014 at 01:05

    After quite a bit of playing around I have what I think might be a viable approach:


    Of particular interest is test 05 and 06 in the t/subclasses directory.

    I would appreciate thoughts on how it is implemented, how to improve the documentation, and how to expand the tests. I want to see how it plays with MooX::StrictConstructor in particular, but am unsure just how to include tests for that.

    In the meanwhile, I hope someone finds this of interest. I expect to release it to CPAN within the week unless I receive a reason not to from my fellow monks or one of the Moo demi-gods.

    You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
How to make a progress counter for parsing HTML with HTML::TreeBuilder
2 direct replies — Read more / Contribute
by ambrus
on Oct 30, 2014 at 12:33

    This is the true story of a trivial bug I made in a perl program yesterday.

    This program parses a 3 megabyte sized HTML file using the HTML::TreeBuilder module. The program takes less than 30 seconds to run, but that'ss still boring to wait and I'd like to see whether it hangs, so I decided to add a progress counter. Now, as I haven't written all of the program yet, much of the time is currently spent in just parsing the HTML file and building a tree representation in memory from it. Thus, I needed a progress counter in the HTML parsing itself (as well as one in the rest of the program).

    Before I added the progress counter, all of the HTML parsing happened in just one call of the HTML::TreeBuilder->parse_file method. If I kept that, if would be difficult to add a progress counter in it. Thus, I changed the code to instead read the HTML file in 64 kilobyte chunks, feed them each to the parser with the HTML::TreeBuilder->parse method, and print progress after each according to how much of the file is read.

    I thus wrote this.

    use HTML::TreeBuilder; my $filename = ...; my $tree = HTML::TreeBuilder->new; { open my $fileh, "<", $filename or die qq(error opening input h +tml file "$filename": $!); binmode $fileh; my $filesize = -s $fileh; while (read $fileh, my $buf, (1<<16)) { $tree->parse($buf); printf(STDERR "Parsing html, %2d%%;\r", int(100*tell($ +fileh)/($filesize+1))); } $tree->eof; print STDERR "Parsing html complete. \n"; }

    This worked fine. I got a comforting progress counter with percentages rolling quickly on the screen.

    Later, however, I wanted to work around a bug in the HTML, namely some missing open tags. This can be done mechanically, because this is a generated HTML file, but it was easier if I could modify the text of the HTML before parsing it to the tree, because otherwise the tree would have a wrong shape that would be difficult to fix.

    Thus, I chose to do some substitution on the text of the HTML before parsing it. This was easier by slurping the whole HTML file and doing substitutions on the whole thing. So I changed the code to slurp the file contents, substitute it, but then I still wanted to feed it to HTML::TreeBuilder in chunks to get a nice progress counter. No big deal, I wrote this.

    use HTML::TreeBuilder; my $filename = ...; my $tree = HTML::TreeBuilder->new; { printf STDERR "Reading html file.\n"; open my $fileh, "<", $filename or die qq(error opening input h +tml file "$filename": $!); binmode $fileh; local $/; my $filec = <$fileh>; eof($fileh) or die qq(error reading input html file); printf STDERR "Substing html file.\n"; $filec =~ ...; my $filesize = length $filec; printf STDERR "Substed html has length %d\n", $filesize; my $filetell = 0; while (my$buf = substr $filec, 0, (1<<16), "") { $filetell += length $filec; $tree->parse($buf); printf STDERR "Parsing html: %2d%%;\r", int(100*$filet +ell/($filesize+1)); } $tree->eof; print STDERR "Parsing html complete. \n"; }

    This didn't work. The progress counter started showing very high numbers, going up to tens of thousands of percents. I stopped the program because I was worried it got into an infinite loop repeatedly parsing the same part of the file over and over again, and will build an infinite tree.

    After a while, I found the problem. It turns out that the HTML was parsed correctly, only the progress was displayed wrong.

    Can you spot the bug? I'll reveal the solution under the fold.

RFC: MooX::Restore
1 direct reply — Read more / Contribute
by boftx
on Oct 28, 2014 at 23:01

    I saw this module come across recently: MooseX::Role::UnsafeConstructable

    I immediately thought of a few use-cases where I want to instantiate an object from, say, a database row but having init_arg => undef, in my Moo code would prevent that.

    As it turns out, it is fairly simple to create a Moo::Role that can provide a new method, possibly named restore that can ignore the init_arg directive and allow one to instantiate a Moo object from a hash or hashref that would otherwise be blocked. A side benefit is that such a method could still call builders and whatnot if needed for attributes that were not stored in the database row.

    My questions are these: a) does anyone else have a similar use-case where it would be handy to do something like my $obj = MyClass->restore( $db_rowref );, bypassing init_arg restrictions, and b) what would be the correct name for such a Role? (I really think "UnsafeConstructable" is a bad choice.)

    I realize there are a few (or more) warts on this, especially where init_arg is used to rename an attribute. I would love to hear thoughts on what one would expect to happen in those cases.

    You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
RFC: QA Uploads
1 direct reply — Read more / Contribute
by mgv
on Oct 27, 2014 at 17:35

    Debian has a process called "QA uploads" if a package is orphaned1, any Debian Developer can upload a new version of the package without adopting it.

    When adopting a package/module, the adopter feels compelled to fix all bugs, add more tests, clean up everything, etc (otherwise they wouldn't be doing their job as maintainers). The amount of work discourages people from adopting modules.

    With QA Uploads, an interested user can fix that particularily annoying bug without the burden of having to maintain the module.

    Thus, I believe that adding QA uploads to PAUSE would increase the average quality of modules. I haven't thought about implementation details, but I think the PAUSE indexer could simply index any upload of an orphaned module.

    1 Debian / CPAN equivalence:
    O: / OrphanedADOPTME has f/m/c
    RFA: / Request for AdoptionHANDOFF has c
    RFH: / Request for HelpNEEDHELP has c
    QA Uploads are only possible for orphaned packages.
Reanimating regular issue: Indirect Object Notation
2 direct replies — Read more / Contribute
by McA
on Oct 27, 2014 at 06:22

    Hi all,

    as a regular reader of the Perlweekly newsletter I stumbled on this entry in Edition #170: Stop using indirect object notation.

    In the same moment I thought: Didn't I ask something related some time ago? Yes, I did. And I found it: Reference needed.

    So, I bring this to awareness once again.

    The reactions on twitter are interesting. IMHO the very first action that could be taken: Change all (changeable) documentation where new Class is used. Because most people don't care. They're copy&pasting the examples and synopsis of CPAN modules. And you can find this indirect notation on CPAN.


zentara is going bye-bye
8 direct replies — Read more / Contribute
by Anonymous Monk
on Oct 25, 2014 at 14:50
    Hello esteemed monks and nerds out there. I post this anonymously because my computer blew out yesterday, and instead of fixing it, or wasteing bucks on another, I decided to let the computer go. I take this cosmic ray hit on my computer, as a sign from God, that wasteing time on the illusion of programming, is just part of Maya, the Great Illusion. It was great fun and all, and taught me alot, but I'm not staying on this planet, and if the karma associated with computers is bad, then getting rid of my computer is good.

    So, I'm not dead, I'm not fading or slowly iterrating away, I just don't see value in wasting time on an illusion.

    So, as final advice, zentara says seek the Vaikunthas, and remember, I'm not ignoring posts, but if God takes your computer away, what can you do? :-)

Refactoring Perl5 with Lua
1 direct reply — Read more / Contribute
by rje
on Oct 21, 2014 at 14:31

    WARNING: It may be that I'm simply thinking about Parrot in a different way...

    If you've read my previous post on microperl, then you're sufficiently prepared to take this post with a grain of salt. As a brief summary, I'll re-quote something Chromatic wrote to start me thinking about this problem in general:

    "If I were to implement a language now, I'd write a very minimal core suitable for bootstrapping. ... Think of a handful of ops. Think very low level. (Think something a little higher than the universal Turing machine and the lambda calculus and maybe a little bit more VMmy than a good Forth implementation, and you have it.) If you've come up with something that can replace XS, stop. You're there. Do not continue. That's what you need." (Chromatic, January 2013)

    Warning: I've never written a VM or a bytecode interpreter. I have written interpreters and worked with bytecodes before (okay, a 6502 emulator, but that's basically a bytecode interpreter, right?) Just remember that I'm not posting from a position of strength.

    So I found the Lua opcode set, and it seems a good starting point for talking about a small, though perhaps not minimal, Turing machine that seems to do much of what Chromatic was thinking about... except for XS, which I still haven't wrapped my head around.

    Lua has a register-based 35 opcode VM with flat closures, threads, coroutines, incremental garbage collection... and manages to shoehorn in a tail call, a "for" loop, and a CLOSURE for goodness' sake. And some of those opcodes could be "macros" built on top of other opcodes, rather than atomic opcodes (only if speed were unimportant): SUB, MUL, DIV, POW, LE.

    Again, a disclaimer: I haven't been in a compiler construction class for 25 years, and my career has typically been enterprise coding, data analysis, and tool scripting. Regardless, a small opcode set seems to me to be important for portability. And... 35 codes... well, that's dinky.

    I don't assume that Lua's codes are sufficient for Perl... things are likely missing or just not quite right for Perl. But I have to start somewhere, right? And I figure some of you have the right Domain Knowledge to shed some light on the subject. Right?

    There's lots of neat notes in the aforementioned Lua design doc, written in a clear and concise manner. And now for a brief glance at Lua's opcodes:

On optimizing nested loops
3 direct replies — Read more / Contribute
by FloydATC
on Oct 19, 2014 at 06:05

    While working on a complex script doing lookups and searches on a dozen arrays of hashes (each array representing a relational database table) I stumbled across an extremely simple improvement that instantly gave almost twice the performance.

    The original loop looked like this:

    sub filter { my $where = shift; my @in = @_; # This class method is used to filter an array of hashrefs against a + set of criteria defined in $where. # Example: # @matching_hosts = filter( { site => 56, type => 4 }, @all_hosts) +; # In this example, @matching_hosts will only contain those hashrefs +that would return TRUE for the following code: # ($_->{'site'} eq '56' && $_->{'type'} eq '4') # Note that the "eq" and "&&" are implied; no other operators are su +pported. # The order of the array is not affected. my @out = (); foreach my $record (@in) { my $keep = 1; foreach my $field (keys %{$where}) { unless ($record->{$field} eq $where->{$field}) { $keep = 0; last; } push @out, $record if $keep; } } return @out; }

    The rewritten loop looks like this:

    sub filter { my $where = shift; my @in = @_; # This class method is used to filter an array of hashrefs against a + set of criteria defined in $where. # Example: # @matching_hosts = filter( { site => 56, type => 4 }, @all_hosts) +; # In this example, @matching_hosts will only contain those hashrefs +that would return TRUE for the following code: # ($_->{'site'} eq '56' && $_->{'type'} eq '4') # Note that the "eq" and "&&" are implied; no other operators are su +pported. # The order of the array is not affected. my @out = (); # Make one pass per match term foreach my $field (keys %{$where}) { my $value = $where->{$field}; @out = grep { $_->{$field} eq $value } @in; @in = @out; # Prepare for next pass (if any) } return @out; }

    The running times of actual reports dropped from over 4 seconds to less than 2 seconds. Some of that improvement obviously came from using the built-in grep{} function instead of manually checking each value and push()'ing hashrefs to the @out array, but I didn't expect that much of an improvement.

    There had to be a different explanation, and that got me thinking about the cost of setting up and executing a foreach() loop:

    $ cat foreach_inner #!/usr/bin/perl use strict; use warnings; foreach my $foo (1 .. 3) { foreach my $bar (1 .. 10000000) { my $pointless = "$foo.$bar"; } }
    $ time ./foreach_inner real 0m8.975s user 0m8.954s sys 0m0.013s
    $ cat foreach_outer #!/usr/bin/perl use strict; use warnings; foreach my $foo (1 .. 10000000) { foreach my $bar (1 .. 3) { my $pointless = "$foo.$bar"; } }
    $ time ./foreach_outer real 0m14.106s user 0m14.092s sys 0m0.003s

    Both test scripts do the exact same amount of (pointless) work, the difference between the two scripts is that 'foreach_inner' has to execute 9999997 more foreach() loops than 'foreach_outer'.

    Sometimes, even a seemingly pointless improvement can make a significant difference if made in the right place.

    Now, the way filters are specified in $where is pretty much nailed down because that hashref is built and used in a lot of different contexts. I am still looking for a way to express the whole thing as a single grep{} block to eliminate the looping altogether. Maybe tomorrow.

    -- FloydATC

    Time flies when you don't know what you're doing

Add your Meditation
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.