Comparisons to Other Languages

4.5.1 Tcl

Tcl programmers rely heavily on dynamic evaluation (using eval) to pass around bits and pieces of code. While you can do this in Perl also, Perl's anonymous subroutines are packets of precompiled code, which definitely work faster than dynamic evaluation. Perl closures give you other advantages that are not available in Tcl: the ability to share private variables between different closures (in Tcl, they have to be global variables for them to be sharable) and not worry about variable interpolation rules (in Tcl, you have to take care to completely expand all the variables yourself using interpolation before you pass a piece of code along to somebody else).

4.5.2 Python

Python offers a weak form of closures: a subroutine can pick up variables only from its immediate containing environment. This is called "shallow binding," while Perl offers "deep binding." Mark Lutz's Programming Python (O'Reilly, 1996) shows a workaround to achieve deep binding, by setting default arguments to values in the immediately enclosing scope.

I prefer the environment to handle this stuff automatically for me, as Perl does.

4.5.3 C++

C++ supports pointers to subroutines but does not support closures. You have to use the callback object idiom wherever a callback subroutine needs some contextual data to operate. If you don't want a separate callback object, you can inherit your object from a standard callback class and override a method called, say, "execute," so that the caller can simply say callback_object->execute().

4.5.4 Java

Java offers neither closures nor pointers to subroutines (methods). Interfaces can be used to provide a standardized callback interface so that the caller doesn't have to care about the specific class of the object (as long as it implements that interface).

Previous: 4.4 Using Closures Advanced Perl Programming

Next: 4.6 Resources

4.4 Using Closures _Book

Index

4.6 Resources

[ Library Home | Perl in a Nutshell | Learning Perl | Learning Perl on Win32 | Programming Perl | Advanced Perl Programming | Perl Cookbook ]

Previous: 4.5 Comparisons to Other Languages

Chapter 4

Subroutine References and Closures

Next:

5. Eval

4.6 Resources

perlref, perlmod, perlsub, perltoot (Perl documentation).

1.

Structure and Interpretation of Computer Programs. Harold Abelson, Gerald Jay Sussman, Julie Sussman. MIT Press, 1996.

Uses LISP to explain higher-order procedures and closures. A pleasure to read.

2.

Previous: 4.5 Comparisons to Other Languages

Advanced Perl Programming

Next:

5. Eval

4.5 Comparisons to Other Languages

Book Index

5. Eval

[ Library Home | Perl in a Nutshell | Learning Perl | Learning Perl on Win32 | Programming Perl | Advanced Perl Programming | Perl Cookbook ]

Previous: 4.6 Resources

Chapter 5 Next: 5.2 The Block Form:

Exception Handling

5. Eval

Contents:

The String Form: Expression Evaluation The Block Form: Exception Handling Watch Your Quotes

Using Eval for Expression Evaluation Using Eval for Efficiency

Using Eval for Time-Outs Eval in Other Languages Resources

One person's data is another person's program.

- Programming Pearls, Communications of the ACM, Sept. 1985 Years ago, a friend of mine showed me an elegant program running on a tiny 48K machine, the BBC Micro, that accepted any mathematical expression such as sin(x) + cos (x**2) and graphed it.

Fresh from a study of parsers, I'd wondered how many hundreds of lines it took him to write it. He showed me the code; the entire program fit on the small screen. He had used the eval statement provided by BASIC.

Most self-respecting scripting languages such as BASIC (some versions, anyway), Perl, Tcl, LISP, and Python have a feature that clearly sets them apart from systems programming languages like C: the ability to treat character strings as little programs.[1]

[1] On a related note, see the section "Dynamic Behavior" in Section 20.22 for other Perl constructs that set Perl apart from systems programming languages.

For me, Perl's run-time evaluation capability is one of the biggest reasons for using the language. (The other is its terrific support for regular expressions.) I use run-time evaluation for creating little snippets of code on the fly, which then execute at typical Perl speeds (i.e., fast!), for writing sophisticated

interpreters for little languages.[2] The eval function is the gateway to this power. We will use this feature in Chapter 7, Object-Oriented Programming, for creating object accessor functions, and in

Chapter 11, Implementing Object Persistence, for building an SQL query evaluator, among other things.

[2] For a delightful discussion of little languages, do have a look at Jon Bentley's More Programming Pearls [3].

As it turns out, Perl's eval function works in two somewhat distinct ways, depending on the type of its argument. If given a string, eval treats the string as a little program and compiles and executes it (as mentioned above); this is called dynamic expression evaluation. The contents of the string may or may not be known at compile time. Alternatively, if given a block of code - that is, the code is known at compile time - eval traps run-time exceptions.

Dynamic expression evaluation and exception handling are very different topics and one would expect them to be performed by different keywords. Larry Wall once mentioned that he had toyed with the idea of using a different keyword, try, for the exception-handling version, but he was into keyword

conservation at that point. I find that a single keyword actually works well because expressions evaluated on the fly have a greater chance of generating run-time exceptions as code known at compile-time.

In this chapter, you will gain an in-depth understanding of how the two forms of eval work and add an important dimension to your toolkit of idioms.