among Perl hacker
s and members of perl5-porters
. In its efforts to DWYM
and provide a high level of expressiveness, Perl
syntax is hideously contorted
. A bareword
might be a string
, even with use strict
(for instance in code like
). Perl's reserved word
s have their own special syntax
takes a sub
or a code block
as an indirect object
), and user-defined
s with a prototype
, defined at compile time
, can similarly direct parsing.
Any character can be a delimiter if you pick your own delimiters, except some behave differently.
The newsgroup regularly receives posts from people surprised by some parser weirdness. Mostly these are experienced, respected Perl programmers, not clueless newbies. And they're still astounded, at least until directed to examine the parse tree generated by the perl compiler.
perl has a yacc grammar, but, as any word could potentially redirect parsing, it's not much use.
With syntax that starts off tricky, but then changes with the program, it's a miracle that even perl can parse Perl. So it's small wonder that the advice to anyone wishing to parse Perl in some utility is advised that only perl can parse Perl. The problem is that such a parse is necessary in order to write good indenters, cross referencers, syntax highlighting program editors, style checkers and the like.
With the advent of the B module some of these utilities can be "bolted on" to the actual Perl compiler. For instance,
B::Xref is such a cross-referencer. But for some applications (e.g. indenting and highlighting from within Emacs) this is not enough.
Simpleton points out an important distinction, which I have incorporated above, between "Perl" (the language) and "perl" (a compiler and interpreter for Perl).