 | Appendix D Topics We Didn't Mention |  |
The "guts" of Perl are defined well enough that it becomes a relatively straightforward task to embed the Perl compiler/interpreter inside another application (such as has already been done with the Apache web server and the vi text editor), or to extend Perl by connecting it with arbitrary code written in C (or having a C-like interface). In fact, about a third of the online documentation for Perl is specifically devoted to embedding and extending Perl. The perlembed (1), perlapio (1), perlxs (1), perlxstut (1), perlguts (1), and perlcall (1) manpages cover these topics in depth.
And since Perl is freely reusable, you can write your proprietary spreadsheet application, using an embedded Perl to evaluate the expressions in your spreadsheet cells, and not have to pay one cent in royalties for all that power. Joy.
Perl was designed with security in mind. See Chapter 6 of Programming Perl or the perlsec (1) manpage about taint checking. This is the kind of security where you trust the writer of the program, but not the person running it, such as is often the case with setuid programs under UNIX, or server-launched programs anywhere. The Safe module, covered in the Safe(3) manpage and Chapter 7 of Programming Perl, provides something else entirely: the kind of security necessary when executing (as with eval) unchecked code.
No, Perl doesn't really have these, but it's easy to make them using more basic constructs. See Chapter 2 of Programming Perl or the perlsyn (1) manpage.
Sometimes Perl's high-level I/O is a bit too high-level for what you need to do. Chapter 3 of Programming Perl and the perlfunc (1) manpage cover direct access to the raw system calls for I/O.
Although we speak of Perl as compiling your code before executing it, this compiled form is not native object code. Malcolm Beatie's Perl compiler project can produce standalone byte code or compilable C code out of your Perl script. The 5.005 release of Perl is expected to have native code generation included as part of the standard release. See the material in the perlfaq3 (1) manpage about this.
Yes, Perl can interface directly with your commercial database servers, including Oracle, Sybase, Informix, and ODBC, just to name a few. See the database section in the CPAN modules directory for the relevant extension modules.
Using references, you can build data structures of arbitrary complexity. These are discussed in Chapter 4 of Programming Perl, and in the perllol (1), perldsc (1), and perlref (1) manpages. If you prefer an object-oriented data structure, see Chapter 5 of Programming Perl, or the perltoot (1) and perlobj (1) manpages.
Perl can store and pass pointers to functions via the \&funcname notation, and call them indirectly via &$funcptr($args). You can even write functions that create and return new anonymous functions, just as you could in languages like Lisp or Scheme. Such anonymous functions are often called closures. See Chapter 4 of Programming Perl, and the perlsub (1) and perlfaq7 (1) manpages for details.
|  | |
| D.9 Packages |  | D.11 And Other Stuff |