Comments on: Perl source filters: evil or not? http://lispy.wordpress.com/2008/10/08/perl-source-filters-evil-or-not/ (notes from an average programmer studying the hard stuff) Thu, 21 May 2009 01:17:58 +0000 http://wordpress.com/ hourly 1 By: draegtun http://lispy.wordpress.com/2008/10/08/perl-source-filters-evil-or-not/#comment-2280 draegtun Mon, 13 Oct 2008 14:50:51 +0000 http://lispy.wordpress.com/?p=323#comment-2280 Well if you use Source Filters in ones own programs then we're all old enough to accept the trade off & consequences! If you're using it in programs that get released to the wild then make sure it does come with a government health warning attached ;-) I think one of the problems with Source Filters is that it screws up the Perl debugger. Thus the slippery slope starts! In terms of literature, Simon Cozens does have a small section on Source Filters in "Advanced Perl Programming". The modern alternative being pushed instead of Source Filters is <a href="http://search.cpan.org/dist/Devel-Declare/" rel="nofollow">Devel::Declare</a>. This works on the bytecode instead of the source code. Its early doors at the moment but it does show great promise. /I3az/ Well if you use Source Filters in ones own programs then we’re all old enough to accept the trade off & consequences! If you’re using it in programs that get released to the wild then make sure it does come with a government health warning attached ;-)

I think one of the problems with Source Filters is that it screws up the Perl debugger. Thus the slippery slope starts!

In terms of literature, Simon Cozens does have a small section on Source Filters in “Advanced Perl Programming”.

The modern alternative being pushed instead of Source Filters is Devel::Declare. This works on the bytecode instead of the source code. Its early doors at the moment but it does show great promise.

/I3az/

]]> By: lispy http://lispy.wordpress.com/2008/10/08/perl-source-filters-evil-or-not/#comment-2276 lispy Thu, 09 Oct 2008 16:08:07 +0000 http://lispy.wordpress.com/?p=323#comment-2276 Sorry for the irritating error, Mark. I use Perl in three different environments, so I generally forget which way the slashes go until I get shell complaint. Yeah, it works without it as I normally don't take the time to chmod stuff. Sorry for the irritating error, Mark. I use Perl in three different environments, so I generally forget which way the slashes go until I get shell complaint. Yeah, it works without it as I normally don’t take the time to chmod stuff.

]]> By: Mark http://lispy.wordpress.com/2008/10/08/perl-source-filters-evil-or-not/#comment-2274 Mark Thu, 09 Oct 2008 15:53:17 +0000 http://lispy.wordpress.com/?p=323#comment-2274 Why are you using backslashes in the shebang line at the top? Does that even do anything? Won't your code work fine without that line? Why are you using backslashes in the shebang line at the top? Does that even do anything? Won’t your code work fine without that line?

]]> By: Aristotle Pagaltzis http://lispy.wordpress.com/2008/10/08/perl-source-filters-evil-or-not/#comment-2272 Aristotle Pagaltzis Thu, 09 Oct 2008 00:25:49 +0000 http://lispy.wordpress.com/?p=323#comment-2272 Source filters are definitely evil and the online Perl community will generally try to dissuade you from using them. In some extremely limited cases they are useful, but as a regular code structuring tool they are evil evil evil. That is why you won’t find much mention of it in the literature. It is, for all intents and purposes, impossible to transform Perl code correctly. Translating a non-Perl format that has bits of Perl embedded inside it to Perl is OK, so long as you take care never to try to parse the Perl bits, which mainly means parsing the file while considering the Perl bits opaque. (Eg. if you put Perl inside XML: an XML parser won’t care that the text nodes it finds contain Perl, and if there’s any need to use XML metacharacters inside Perl code you have to escape them in the Perl code according to the XML rules. There is then never any ambiguity.) As for Moose, its popularity is simply too new for the module to have found its way into any printed Perl literature. You are definitely trying to do moderately unusual things and based on the fact that you say they are part of a “dream” project, this should really not be surprising to you. :-) I don’t really get why you aren’t just writing a proper parser for an external DSL instead of translating to Perl, though. Source filters are definitely evil and the online Perl community will generally try to dissuade you from using them. In some extremely limited cases they are useful, but as a regular code structuring tool they are evil evil evil. That is why you won’t find much mention of it in the literature. It is, for all intents and purposes, impossible to transform Perl code correctly.

Translating a non-Perl format that has bits of Perl embedded inside it to Perl is OK, so long as you take care never to try to parse the Perl bits, which mainly means parsing the file while considering the Perl bits opaque. (Eg. if you put Perl inside XML: an XML parser won’t care that the text nodes it finds contain Perl, and if there’s any need to use XML metacharacters inside Perl code you have to escape them in the Perl code according to the XML rules. There is then never any ambiguity.)

As for Moose, its popularity is simply too new for the module to have found its way into any printed Perl literature.

You are definitely trying to do moderately unusual things and based on the fact that you say they are part of a “dream” project, this should really not be surprising to you. :-)

I don’t really get why you aren’t just writing a proper parser for an external DSL instead of translating to Perl, though.

]]>