Any comments before I send this off? .robin.
Type: talk Duration: 40 mins Title: Mutagenic Modules Slides (draft version): http://London.pm.org/~robin/semantic-talk/0.title.html Abstract: It's possible to write a Perl module which will change the meaning of subsequent code in some way. Pragmas (eg "use integer") alter meaning in this way, but require significant co-operation from the perl interpreter. However, there are many different ways that you can write your own "mutagenic modules". Mechanisms that make this possible include: * AUTOLOAD * CORE::UNIVERSAL:: * overload::constant * source filters * CHECK blocks * tie() ...and many more. You can do a lot of fun, interesting tricks using these mechanisms, and I shall demonstrate several different examples; but there are limits to what you can do. To take a simple example, there's no general way to change the behaviour of the print function. I'll briefly mention the difficulties I encountered trying to implement the mythical Symbol::Approx::Scalar module. Next I present a brief overview of the internal workings of the perl interpreter: How it parses your code and compiles it into an optree, and how the optree is then executed. A compiler backend (or, to speak more generally, a CHECK block) interposes itself between these two stages, and converts the optree into some other form. My favourite compiler backend is B::Deparse, which just converts the optree back into Perl source code! Finally I'll describe some work (currently still in the planning phase) to use a Deparse-like module to convert the optree into a structured object model which represents the original code. This object model can serialise itself as Perl code; but serialisation of any specific construct can be over-ridden to produce different code. (The objects will also have methods which enumerate the lexical variables which are in-scope at that point in the program.) This then amounts to a perfectly general mechanism for applying any kind of semantic transformation to any Perl code.
