Interpolation - Page 173

Interpolation is the feature by which the Perl interpreter expands expressions on-the-fly. For example in Perl 5 we might say:

print "My favorite color is $color.\n";

Perl would substitute the value of $color in the output above, along with a newline character, because the expression is enclosed within double quotation marks and Perl 5 interpolates within double quotation marks. It does not interpolate within single quotation marks, and so the statement:

print 'My favorite color is $color.\n";

Would be treated literally, and Perl 5 would output it exactly as written, which is probably not what the coder wants. The difficulty with these interpolation rules is that sometimes you want a mixture of interpolated and non-interpolated expressions, and constructing such a thing is messy looking in Perl 5.

Larry Wall's proposal for Perl 6 is to introduce a special interpolating and non-interpolating expression, \qq and \q respectively. For example:

print "The variable \q{$color}=$color\n";
print 'The variable $color=\qq{$color\n}";

Both examples, if the value of $color were "green," would produce the output:

The variable $color=green

Interpolation may also be introduced for variable prefix types. That may not make much sense on the face of it, but consider interpolating a scalar variable:

$(@colors[0])++;

If the first item of @colors were "green" then the above line would be interpreted by Perl 6 as if we had written:

$green++;

On a related note, however, Perl 6 dispenses with the convention:

$#listname

to retrieve the index of the last element in a list. Instead we use the new object oriented approach, calling on the end() method of a list:

listname.end

Objects and Properties

The last example also introduces a new syntax for working with objects. Perl 5 used the -> symbol to call a method of an object, which Perl 6 replaces with a single dot character:

object.method

Because variables and even subroutines in Perl 6 are objects they gain some new capabilities. Of particular interest are properties, which in Perl 6 is defined as akin to a "sticky note" — information that you want to attach to a variable (or subroutine), but is not its value, per se. Rather, an annotation of sorts. For example, suppose you want to annotate a scalar variable as being constant — that is, it's value should not change. The "is" syntax lets you stack property annotations onto a variable (or a value or a subroutine) as follows:

my str $copyright is constant="(c) 2001 Me Enterprises";

Some properties may be built-in for a particular type, so the "constant" annotation may intrinsically mean something to Perl. Or, it may not, in which case the annotation is there for your program to later heed or ignore. Properties can be stacked and also supplied values — reconsider the example above with a new property stacked on:

my str $copyright is constant style('tiny')="(c)
 2001 Me Enterprises";

[The lines above are one line. They have been split for formatting purposes.]

These properties are stored as a hash stuck to their owner. The property names are hash keys and the values, if supplied in parentheses as in the example, are the hash values. So the hash stuck to $copyright would have two keys, constant and style, the latter having the value 'tiny'. It may be that later in our program the style attribute is accessed and appropriate output rendering code is used to style the text for some medium such as a Web page.

High Philosophy

The development of Perl 6 ranges from decisions over syntax to philosophical tenants. Perl 5 has operated, by default, in a lax mode that didn't do strict checks on certain conventions. This was great for quick and functional code, but lax programming could bite back in other environments, especially mod_perl for example. The "use strict" mode in Perl 5 is often called upon to enforce good practice, and one debate swirling around Perl 6 is whether it should be strict by default, or, like Perl 5, ask the programmer to opt-out of laziness.

Another high-minded subject of Perl 6 development is whether there should ever be a Perl 7. On its face this may seem like an obvious or even irrelevant question. But actually, it has a point. The question boils down to whether Perl 6 can and will be ambitious and extensible enough that one cannot envision a need for a Perl 7, or whether Perl 6 is developed within clear enough boundaries that another future revision remains within sight. Ambitious though it may seem, though, lead architect Larry Wall is generally in favor of not looking beyond Perl 6. His aim is to make the language so flexible, accounting for different syntaxes and even multiple platforms (such as Java), that Perl 6 should march on for 20 years.

One thing is for sure: although there will be much more Perl that you need to know, we've reached the end of the Perl You Need to Know series. In over two years and 25 installments we've come to a paradox, having covered so much ground and yet so little. The conclusion to the Perl You Need to Know series is not a suggestion that Perl doesn't go far deeper and wider than this series, but rather that only the mandate of this series itself has reached its end. With the promise of 20 years of Perl 6 ahead there's no end in sight.

Whither Perl 5? - Page 172
The Perl You Need to Know