1Perl6::Bible::A02(3) User Contributed Perl Documentation Perl6::Bible::A02(3)
2
6 Apocalypse_02 - Bits and Pieces
7
9 Larry Wall <larry@wall.org>
10
12 Maintainer: Larry Wall <larry@wall.org>
13 Date: 3 May 2001
14 Last Modified: 4 Dec 2004
15 Number: 2
16 Version: 4
17 Here's Apocalypse 2, meant to be read in conjunction with Chapter 2 of
19 the Camel Book. The basic assumption is that if Chapter 2 talks about
20 something that I don't discuss here, it doesn't change in Perl 6. (Of
21 course, it could always just be an oversight. One might say that people
22 who oversee things have a gift of oversight.)
23 Before I go further, I would like to thank all the victims, er, partic‐
25 ipants in the RFC process. (I beg special forgiveness from those whose
26 brains I haven't been able to get inside well enough to incorporate
27 their ideas). I would also like to particularly thank Damian Conway,
28 who will recognize many of his systematic ideas here, including some
29 that have been less than improved by my meddling.
30 Here are the RFCs covered:
32 RFC PSA Title
34 --- --- -----
35 Textual
36 005 cdr Multiline Comments for Perl
37 102 dcr Inline Comments for Perl
38 Types
40 161 adb Everything in Perl Becomes an Object
41 038 bdb Standardise Handling of Abnormal Numbers Like Infinities and NaNs
42 043 bcb Integrate BigInts (and BigRats) Support Tightly With the Basic Scalars
43 192 ddr Undef Values ne Value
44 212 rrb Make Length(@array) Work
45 218 bcc C<my Dog $spot> Is Just an Assertion
46 Variables
48 071 aaa Legacy Perl $pkg'var Should Die
49 009 bfr Highlander Variable Types
50 133 bcr Alternate Syntax for Variable Names
51 134 bcc Alternative Array and Hash Slicing
52 196 bcb More Direct Syntax for Hashes
53 201 bcr Hash Slicing
54 Strings
56 105 aaa Remove "In string @ must be \@" Fatal Error
57 111 aaa Here Docs Terminators (Was Whitespace and Here Docs)
58 162 abb Heredoc Contents
59 139 cfr Allow Calling Any Function With a Syntax Like s///
60 222 abb Interpolation of Object Method Calls
61 226 acr Selective Interpolation in Single Quotish Context
62 237 adc Hashes Should Interpolate in Double-Quoted Strings
63 251 acr Interpolation of Class Method Calls
64 252 abb Interpolation of Subroutines
65 327 dbr C<\v> for Vertical Tab
66 328 bcr Single Quotes Don't Interpolate \' and \\
67 Files
69 034 aaa Angle Brackets Should Not Be Used for File Globbing
70 051 ccr Angle Brackets Should Accept Filenames and Lists
71 Lists
73 175 rrb Add C<list> Keyword to Force List Context (like C<scalar>)
74 Retracted
76 010 rr Filehandles Should Use C<*> as a Type Prefix If Typeglobs Are Eliminated
77 103 rr Fix C<$pkg::$var> Precedence Issues With Parsing of C<::>
78 109 rr Less Line Noise - Let's Get Rid of @%
79 245 rr Add New C<empty> Keyword to DWIM for Clearing Values
80 263 rr Add Null() Keyword and Fundamental Data Type
81
83 Perl 6 programs are notionally written in Unicode, and assume Unicode
84 semantics by default even when they happen to be processing other char‐
85 acter sets behind the scenes. Note that when we say that Perl is writ‐
86 ten in Unicode, we're speaking of an abstract character set, not any
87 particular encoding. (The typical program will likely be written in
88 UTF-8 in the West, and in some 16-bit character set in the East.)
89
91 RFC 005: Multiline Comments for Perl
92 I admit to being prejudiced on this one -- I was unduly influenced at a
94 tender age by the rationale for the design of Ada, which made a good
95 case, I thought, for leaving multiline comments out of the language.
96 But even if I weren't blindly prejudiced, I suspect I'd look at the
98 psychology of the thing, and notice that much of the time, even in lan‐
99 guages that have multiline comments, people nevertheless tend to use
100 them like this:
101 /*
103 * Natter, natter, natter.
104 * Gromish, gromish, gromish.
105 */
106 The counterargument to that is, of course, that people don't always do
108 that in C, so why should they have to do it in Perl? And if there were
109 no other way to do multiline comments in Perl, they'd have a stronger
110 case. But there already is another way, albeit one rejected by this RFC
111 as "a workaround."
112 But it seems to me that, rather than adding another kind of comment or
114 trying to make something that looks like code behave like a comment,
115 the solution is simply to fix whatever is wrong with POD so that its
116 use for commenting can no longer be considered a workaround. Actual
117 design of POD can be put off till Apocalypse 26, but we can speculate
118 at this point that the rules for switching back and forth between POD
119 and Perl are suboptimal for use in comments. If so, then it's likely
120 that in Perl 6 we'll have a rule like this: If a "=begin MUMBLE" tran‐
121 sitions from Perl to POD mode then the corresponding "=end MUMBLE"
122 should transition back (without a "=cut" directive).
123 Note that we haven't defined our "MUMBLE"s yet, but they can be set up
125 to let our program have any sort of programmatic access to the data
126 that we desire. For instance, it is likely that comments of this kind
127 could be tied in with some sort of literate (or at least, semiliterate)
128 programming framework.
129 RFC 102: Inline Comments for Perl
131 I have never much liked inline comments -- as commonly practiced they
133 tend to obfuscate the code as much as they clarify it. That being said,
134 "All is fair if you predeclare." So there should be nothing preventing
135 someone from writing a lexer regex that handles them, provided we make
136 the lexer sufficiently mutable. Which we will. (As it happens, the
137 character sequence ""/*"" will be unlikely to occur in standard Perl 6.
138 Which I guess means it is likely to occur in nonstandard Perl 6. ":-)"
139 A pragma declaring nonstandard commenting would also allow people to
141 use "/* */" for multiline comments, if they like. (But I still think
142 it'd be better to use POD directives for that, just to keep the text
143 accessible to the program.)
144
146 The basic change here is that, rather than just supporting scalars,
147 arrays and hashes, Perl 6 supports opaque objects as a fourth fundamen‐
148 tal data type. (You might think of them as pseudo-hashes done right.)
149 While a class can access its object attributes any way it likes, all
150 external access to opaque objects occurs through methods, even for
151 attributes. (This guarantees that attribute inheritance works cor‐
152 rectly.)
153 While Perl 6 still defaults to typeless scalars, Perl will be able to
155 give you more performance and safety as you give it more type informa‐
156 tion to work with. The basic assumption is that homogenous data struc‐
157 tures will be in arrays and hashes, so you can declare the type of the
158 scalars held in an array or hash. Heterogenous structures can still be
159 put into typeless arrays and hashes, but in general Perl 6 will encour‐
160 age you to use classes for such data, much as C encourages you to use
161 structs rather than arrays for such data.
162 One thing we'll be mentioning before we discuss it in detail is the
164 notion of "properties." (In Perl 5, we called these "attributes," but
165 we're reserving that term for actual object attributes these days, so
166 we'll call these things "properties.") Variables and values can have
167 additional data associated with them that is "out of band" with respect
168 to the ordinary typology of the variable or value. For now, just think
169 of properties as a way of adding ad hoc attributes to a class that
170 doesn't support them. You could also think of it as a form of class
171 derivation at the granularity of the individual object, without having
172 to declare a complete new class.
173 [Update: We're now calling compile-time properties "traits".]
175 RFC 161: Everything in Perl Becomes an Object.
177 This is essentially a philosophical RFC that is rather short on detail.
179 Nonetheless, I agree with the premise that all Perl objects should act
180 like objects if you choose to treat them that way. If you choose not to
181 treat them as objects, then Perl will try to go along with that, too.
182 (You may use hash subscripting and slicing syntax to call attribute
183 accessors, for instance, even if the attributes themselves are not
184 stored in a hash.) Just because Perl 6 is more object-oriented inter‐
185 nally, does not mean you'll be forced to think in object-oriented terms
186 when you don't want to. (By and large, there will be a few places where
187 OO-think is more required in Perl 6 than in Perl 5. Filehandles are
188 more object-oriented in Perl 6, for instance, and the special variables
189 that used to be magically associated with the currently selected output
190 handle are better specified by association with a specific filehandle.)
191 RFC 038: Standardise Handling Of Abnormal Numbers Like Infinities and
193 NaNs
194 This is likely to slow down numeric processing in some locations. Per‐
196 haps it could be turned off when desirable. We need to be careful not
197 to invent something that is guaranteed to run slower than IEEE floating
198 point. We should also try to avoid defining a type system that makes
199 translation of numeric types to Java or C# types problematic.
200 That being said, standard semantics are a good thing, and should be the
202 default behavior.
203 RFC 043: Integrate BigInts (and BigRats) Support Tightly With the Basic
205 Scalars
206 This RFC suggests that a pragma enables the feature, but I think it
208 should probably be tied to the run-time type system, which means it's
209 driven more by how the data is created than by where it happens to be
210 stored or processed. I don't see how we can make it a pragma, except
211 perhaps to influence the meaning of "int" and "num" in actual declara‐
212 tions further on in the lexical scope:
213 use bigint;
215 my int $i;
216 might really mean
218 my bigint $i;
220 or maybe just
222 my int $i is bigint;
224 since representation specifications might just be considered part of
226 the "fine print." But the whole subject of lexically scoped variable
227 properties specifying the nature of the objects they contain is a bit
228 problematic. A variable is a sort of mini-interface, a contract if you
229 will, between the program and the object in question. Properties that
230 merely influence how the program sees the object are not a problem --
231 when you declare a variable to be constant, you're promising not to
232 modify the object through that variable, rather than saying something
233 intrinsically true about the object. (Not that there aren't objects
234 that are intrinsically constant.)
235 Other property declarations might need to have some say in how con‐
237 structors are called in order to guarantee consistency between the
238 variable's view of the object, and the nature of the object itself. In
239 the worst case we could try to enforce consistency at run time, but
240 that's apt to be slow. If every assignment of a "Dog" object to a "Mam‐
241 mal" variable has to check to see whether "Dog" is a "Mammal", then the
242 assignment is going to be a dog.
243 So we'll have to revisit this when we're defining the relationship
245 between variable declarations and constructors. In any event, if we
246 don't make Perl's numeric types automatically promote to big represen‐
247 tations, we should at least make it easy to specify it when you want
248 that to happen.
249 [Update: The "Int" type automatically upgrades to arbitrary precision
251 internally. The "int" type does not.]
252 RFC 192: Undef Values ne Value
254 I've rejected this one, because I think something that's undefined
256 should be considered just that, undefined. I think the standard seman‐
257 tics are useful for catching many kinds of errors.
258 That being said, it'll hopefully be easy to modify the standard opera‐
260 tors within a particular scope, so I don't think we need to think that
261 our way to think is the only way to think, I think.
262 RFC 212: Make "length(@array)" Work
264 Here's an oddity, an RFC that the author retracted, but that I accept,
266 more or less. I think "length(@array)" should be equivalent to
267 "@array.length()", so if there's a "length" method available, it should
268 be called.
269 The question is whether there should be a "length" method at all, for
271 strings or arrays. It almost makes more sense for arrays than it does
272 for strings these days, because when you talk about the length of a
273 string, you need to know whether you're talking about byte length or
274 character length. So we may split up the traditional length function
275 into two, in which case we might end up with:
276 $foo.chars
278 $foo.bytes
279 @foo.elems
280 Or some such. Whatever the method names we choose, differentiating them
282 would be more powerful in supplying context. For instance, one could
283 envision calling "@foo.bytes" to return the byte length of all the
284 strings. That wouldn't fly if we overloaded the method name.
285 Even "chars($foo)" might not be sufficiently precise, since, depending
287 on how you're processing Unicode, you might want to know how long the
288 string is in actual characters, not counting combining characters that
289 don't take extra space. But that's a topic for later.
290 [Update: There is no "length" function. There are "bytes", "codes",
292 "graphs", and "langs" methods for the various Unicode support levels.
293 (The "chars" method returns one of those values depending on the cur‐
294 rent Unicode support level.) Arrays and hashes report number of ele‐
295 ments with the "elems" method.]
296 RFC 218: "my Dog $spot" Is Just an Assertion
298 I expect that a declaration of the form:
300 my Dog $spot;
302 is merely an assertion that you will not use $spot inconsistently with
304 it being a "Dog". (But I mean something different by "assertion" than
305 this RFC does.) This assertion may or may not be tested at every
306 assignment to $spot, depending on pragmatic context. This bare decla‐
307 ration does not call a constructor; however, there may be forms of dec‐
308 laration that do. This may be necessary so that the variable and the
309 object can pass properties back and forth, and in general, make sure
310 they're consistent with each other. For example, you might declare an
311 array with a multidimensional shape, and this shape property needs to
312 be visible to the constructor, if we don't want to have to specify it
313 redundantly.
314 On the other hand, we might be able to get assignment sufficiently
316 overloaded to accomplish the same goal, so I'm deferring judgment on
317 that. All I'm deciding here is that a bare declaration without argu‐
318 ments as above does not invoke a constructor, but merely tells the com‐
319 piler something.
320 [Update: The constructor may be called using the ".=new()" construct.]
322 Other Decisions About Types
324 Built-in object types will be in all uppercase: "INTEGER", "NUMBER",
326 "STRING", "REF", "SCALAR", "ARRAY", "HASH", "REGEX" and "CODE". Corre‐
327 sponding to at least some of these, there will also be lowercase
328 intrinsic types, such as "int", "num", "str" and "ref". Use of the low‐
329 ercase typename implies you aren't intending to do anything fancy OO-
330 wise with the values, or store any run-time properties, and thus Perl
331 should feel free to store them compactly. (As a limiting case, objects
332 of type "bit" can be stored in one bit.) This distinction corresponds
333 roughly to the boxed/unboxed distinction of other computer languages,
334 but it is likely that Perl 6 will attempt to erase the distinction for
335 you to the extent possible. So, for instance, an "int" may still be
336 used in a string context, and Perl will convert it for you, but it
337 won't cache it, so the next time you use it as a string, it will have
338 to convert again.
339 [Update: The object types are no longer all caps, but "Int", "Num",
341 "Str", etc.]
342 The declared type of an array or hash specifies the type of each ele‐
344 ment, not the type of an array or hash as a whole. This is justified by
345 the notion that an array or hash is really just a strange kind of func‐
346 tion that (typically) takes a subscript as an argument and returns a
347 value of a particular type. If you wish to associate a type with the
348 array or hash as a whole, that involves setting a "tie" property. If
349 you find yourself wishing to declare different types on different ele‐
350 ments, it probably means that you should either be using a class for
351 the whole heterogenous thing, or at least declare the type of array or
352 hash that will be a base class of all the objects it will contain.
353 Of course, untyped arrays and hashes will be just as acceptable as they
355 are currently. But a language can only run so fast when you force it to
356 defer all type checking and method lookup till run time.
357 The intent is to make use of type information where it's useful, and
359 not require it where it's not. Besides performance and safety, one
360 other place where type information is useful is in writing interfaces
361 to other languages. It is postulated that Perl 6 will provide enough
362 optional type declaration syntax that it will be unnecessary to write
363 XS-style glue in most cases.
364
366 RFC 071: Legacy Perl $pkg'var Should Die
367 I agree. I was unduly influenced by Ada syntax here, and it was a mis‐
369 take. And although we're adding a properties feature into Perl 6 that
370 is much like Ada's attribute feature, we won't make the mistake of
371 reintroducing a syntax that drives highlighting editors nuts. We'll try
372 to make different mistakes this time.
373 RFC 009: Highlander Variable Types
375 I basically agree with the problem this RFC is trying to solve, but I
377 disagree with the proposed solution. The basic problem is that, while
378 the idiomatic association of $foo[$bar] with @foo rather than $foo
379 worked fine in Perl 4, when we added recursive data structures to Perl
380 5, it started getting in the way notationally, so that initial funny
381 character was trying to do too much in both introducing the "root" of
382 the reference, as well as the context to apply to the final subscript.
383 This necessitated odd looking constructions like:
384 $foo->[1][2][3]
386 This RFC proposes to solve the dilemma by unifying scalar variables
388 with arrays and hashes at the name level. But I think people like to
389 think of $foo, @foo and %foo as separate variables, so I don't want to
390 break that. Plus, the RFC doesn't unify &foo, while it's perfectly pos‐
391 sible to have a reference to a function as well as a reference to the
392 more ordinary data structures.
393 So rather than unifying the names, I believe all we have to do is unify
395 the treatment of variables with respect to references. That is, all
396 variables may be thought of as references, not just scalars. And in
397 that case, subscripts always dereference the reference implicit in the
398 array or hash named on the left.
399 This has two major implications, however. It means that Perl program‐
401 mers must learn to write @foo[1] where they used to write $foo[1]. I
402 think most Perl 5 people will be able to get used to this, since many
403 of them found the current syntax a bit weird in the first place.
404 The second implication is that slicing needs a new notation, because
406 subscripts no longer have their scalar/list context controlled by the
407 initial funny character. Instead, the context of the subscript will
408 need to be controlled by some combination of:
409 1. Context of the entire term.
411 2. Appearance of known list operators in the subscript, such as comma
412 or range.
413 3. Explicit syntax casting the inside of the subscript to list or
414 scalar context.
415 4. Explicit declaration of default behavior.
416 One thing that probably shouldn't enter into it is the run-time type of
418 the array object, because context really needs to be calculated at com‐
419 pile time if at all possible.
420 In any event, it's likely that some people will want subscripts to
422 default to scalars, and other people will want them to default to
423 lists. There are good arguments for either default, depending on
424 whether you think more like an APL programmer or a mere mortal.
425 [Update: Subscripts are always list context, but it's trivial to force
427 scalar context with either of the "+" or "~" unary operators.]
428 There are other larger implications. If composite variables are thought
430 of as scalar references, then the names @foo and %foo are really scalar
431 variables unless explicitly dereferenced. That means that when you men‐
432 tion them in a scalar context, you get the equivalent of Perl 5's
433 "\@foo" and "\%foo". This simplifies the prototyping system greatly, in
434 that an operator like "push" no longer needs to specify some kind of
435 special reference context for its first argument -- it can merely spec‐
436 ify a scalar context, and that's good enough to assume the reference
437 generation on its first argument. (Of course, the function signature
438 can always be more specific if it wants to. More about that in future
439 installments.)
440 There are also implications for the assignment operator, in that it has
442 to be possible to assign array references to array variables without
443 accidentally invoking list context and copying the list instead of the
444 reference to the list. We could invent another assignment operator to
445 distinguish the two cases, but at the moment it looks as though bare
446 variables and slices will behave as lvalues just as they do in Perl 5,
447 while lists in parentheses will change to a binding of the right-hand
448 arguments more closely resembling the way Perl 6 will bind formal argu‐
449 ments to actual arguments for function calls. That is to say,
450 @foo = (1,2,3);
452 will supply an unbounded list context to the right side, but
454 (@foo, @bar) = (@bar, @foo)
456 will supply a context to the right side that requests two scalar values
458 that are array references. This will be the default for unmarked vari‐
459 ables in an lvalue list, but there will be an easy way to mark formal
460 array and hash parameters to slurp the rest of the arguments with list
461 context, as they do by default in Perl 5.
462 (Alternately, we might end up leaving the ordinary list assignment
464 operator with Perl 5 semantics, and define a new assignment operator
465 such as ":=" that does signatured assignment. I can argue that one both
466 ways.)
467 [Update: We ended up with a ":=" binding operator.]
469 Just as arrays and hashes are explicitly dereferenced via subscripting
471 (or implicitly dereferenced in list context), so too functions are
472 merely named but not called by &foo, and explicitly dereferenced with
473 parentheses (or by use as a bare name without the ampersand (or both)).
474 The Perl 5 meanings of the ampersand are no longer in effect, in that
475 ampersand will no longer imply that signature matching is suppressed --
476 there will be a different mechanism for that. And since &foo without
477 parens doesn't do a call, it is no longer possible to use that syntax
478 to automatically pass the @_ array -- you'll have to do that explicitly
479 now with "foo(@_)".
480 Scalar variables are special, in that they may hold either references
482 or actual "native" values, and there is no special dereference syntax
483 as there is for other types. Perl 6 will attempt to hide the distinc‐
484 tion as much as possible. That is, if $foo contains a native integer,
485 calling the "$foo.bar" method will call a method on the built-in type.
486 But if $foo contains a reference to some other object, it will call the
487 method on that object. This is consistent with the way we think about
488 overloading in Perl 5, so you shouldn't find this behavior surprising.
489 It may take special syntax to get at any methods of the reference vari‐
490 able itself in this case, but it's OK if special cases are special.
491 RFC 133: Alternate Syntax for Variable Names
493 This RFC has a valid point, but in fact we're going to do just the
495 opposite of what it suggests. That is, we'll consider the funny charac‐
496 ters to be part of the name, and use the subscripts for context. This
497 works out better, because there's only one funny character, but many
498 possible forms of dereferencing.
499 RFC 134: Alternative Array and Hash Slicing
501 We're definitely killing Perl 5's slice syntax, at least as far as
503 relying on the initial character to determine the context of the sub‐
504 script. There are many ways we could reintroduce a slicing syntax, some
505 of which are mentioned in this RFC, but we'll defer the decision on
506 that till Apocalypse 9 on Data Structures, since the interesting parts
507 of designing slice syntax will be driven by the need to slice multidi‐
508 mensional arrays.
509 [Update: There is no Apocalypse 9, but there is a Synopsis 9 that cov‐
511 ers these matters.]
512 For now we'll just say that arrays can have subscript signatures much
514 like functions have parameter signatures. Ordinary one-dimensional
515 arrays (and hashes) can then support some kind of simple slicing syntax
516 that can be extended for more complicated arrays, while allowing multi‐
517 dimensional arrays to distinguish between simple slicing and compli‐
518 cated mappings of lists and functions onto subscripts in a manner more
519 conducive to numerical programming.
520 On the subject of hash slices returning pairs rather than values, we
522 could distinguish this with special slice syntax, or we could establish
523 the notion of a hashlist context that tells the slice to return pairs
524 rather than just values. (We may not need a special slice syntax for
525 that if it's possible to typecast back and forth between pair lists and
526 ordinary lists.)
527 [Update: Slicing to get a pairlist can be done by attaching a ":p" mod‐
529 ifier to the subscript.]
530 RFC 196: More Direct Syntax for Hashes
532 This RFC makes three proposals, which we'll consider separately.
534 Proposal 1 is "that a hash in scalar context evaluate to the number of
536 keys in the hash." (You can find that out now, but only by using the
537 "keys()" function in scalar context.) Proposal 1 is OK if we change
538 "scalar context" to "numeric context," since in scalar context a hash
539 will produce a reference to the hash, which just happens to numify to
540 the number of entries.
541 We must also realize that some implementations of hash might have to go
543 through and count all the entries to return the actual number. Fortu‐
544 nately, in boolean context, it suffices to find a single entry to
545 determine whether the hash contains anything. However, on hashes that
546 don't keep track of the number of entries, finding even one entry might
547 reset any active iterator on the hash, since some implementations of
548 hash (in particular, the ones that don't keep track of the number of
549 entries) may only supply a single iterator.
550 [Update: You may also call ".elems" to be more explicit.]
552 Proposal 2 is "that the iterator in a hash be reset through an explicit
554 call to the "reset()" function." That's fine, with the proviso that it
555 won't be a function, but rather a method on the HASH class.
556 Proposal 3 is really about "sort" recognizing pairs and doing the right
558 thing. Defaulting to sorting on $^a[0] cmp $^b[0] is likely to be rea‐
559 sonable, and that's where a pair's key would be found. However, it's
560 probable that the correct solution is simply to provide a default
561 string method for anonymous lists that happens to produce a decent key
562 to sort on when "cmp" requests a string representation of either of its
563 arguments. The "sort" itself should probably just concentrate on memo‐
564 izing the returned strings so they don't have to be recalculated.
565 [Update: The "sort" interface has been completely revamped since this
567 was written. This will eventually appear in S29, but as of now it's
568 just in the perl6-language archives.]
569 RFC 201: Hash Slicing
571 This RFC proposes to use "%" as a marker for special hash slicing in
573 the subscript. Unfortunately, the "%" funny character will not be
574 available for this use, since all hash refs will start with "%". Con‐
575 cise list comprehensions will require some other syntax within the sub‐
576 script, which will hopefully generalize to arrays as well.
577 Other Decisions About Variables
579 Various special punctuation variables are gone in Perl 6, including all
581 the deprecated ones. (Non-deprecated variables will be replaced by some
582 kind of similar functionality that is likely to be invoked through some
583 kind of method call on the appropriate object. If there is no appropri‐
584 ate object, then a named global variable might provide similar func‐
585 tionality.)
586 Freeing up the various bracketing characters allows us to use them for
588 other purposes, such as interpolation of expressions:
589 "$(expr)" # interpolate a scalar expression
591 "@(expr)" # interpolate a list expression
592 [Update: Those forms are gone now. Expression interpolation is done
594 via closure.]
595 $#foo is gone. If you want the final subscript of an array, and "[-1]"
597 isn't good enough, use "@foo.end" instead.
598 Other special variables (such as the regex variables) will change from
600 dynamic scoping to lexical scoping. It is likely that even $_ and @_
601 will be lexically scoped in Perl 6.
602
604 In Perl 5, lexical scopes are unnamed and unnameable. In Perl 6, the
605 current lexical scope will have a name that is visible within the lexi‐
606 cal scope as the pseudo class "MY", so that such a scope can, if it so
607 chooses, delegate management of its lexical scope to some other module
608 at compile time. In normal terms, that means that when you use a mod‐
609 ule, you can let it import things lexically as well as packagely.
610 Typeglobs are gone. Instead, you can get at a variable object through
612 the symbol table hashes that are structured much like Perl 5's. The
613 variable object for $MyPackage::foo is stored in:
614 %MyPackage::{'$foo'}
616 Note that the funny character is part of the name. There is no longer
618 any structure in Perl that associates everything with the name ""foo"".
619 Perl's special global names are stored in a special package named ""*""
621 because they're logically in every scope that does not hide them. So
622 the unambiguous name of the standard input filehandle is $*STDIN, but a
623 package may just refer to $STDIN, and it will default to $*STDIN if no
624 package or lexical variable of that name has been declared.
625 [Update: We did s/STD// on those, so standard input is now just $*IN.]
627 Some of these special variables may actually be cloned for each lexical
629 scope or each thread, so just because a name is in the special global
630 symbol table doesn't mean it always behaves as a global across all mod‐
631 ules. In particular, changes to the symbol table that affect how the
632 parser works must be lexically scoped. Just because I install a special
633 rule for my cool new hyperquoting construct doesn't mean everyone else
634 should have to put up with it. In the limiting case, just because I
635 install a Python parser, it shouldn't force other modules into a maze
636 of twisty little whitespace, all alike.
637 Another way to look at it is that all names in the ""*"" package are
639 automatically exported to every package and/or outer lexical scope.
640
642 Underscores in Numeric Literals
643 Underscores will be allowed between any two digits within a number.
645 RFC 105: Remove "In string @ must be \@" Fatal Error
647 Fine.
649 [Update: The interpolation rules for arrays have been completely
651 revised. A bare array name no longer interpolates--you have to say
652 @foo[].]
653 RFC 111: Here Docs Terminators (Was Whitespace and Here Docs)
655 Fine.
657 RFC 162: Heredoc contents
659 I think I like option (e) the best: remove whitespace equivalent to the
661 terminator.
662 By default, if it has to dwim, it should dwim assuming that hard tabs
664 are 8 spaces wide. This should not generally pose a problem, since most
665 of the time the tabbing will be consistent throughout anyway, and no
666 dwimming will be necessary. This puts the onus on people using nonstan‐
667 dard tabs to make sure they're consistent so that Perl doesn't have to
668 guess.
669 Any additional mangling can easily be accomplished by a user-defined
671 operator.
672 RFC 139: Allow Calling Any Function With a Syntax Like s///
674 Creative quoting will be allowed with lexical mutataion, but we can't
676 parse "foo(bar)" two different ways simultaneously, and I'm unwilling
677 to prevent people from using parens as quote characters. I don't see
678 how we can reasonably have new quote operators without explicit decla‐
679 ration. And if the utility of a quote-like operator is sufficient,
680 there should be little relative burden in requiring such a declaration.
681 The form of such a declaration is left to the reader as an exercise in
683 function property definition. We may revisit the question later in this
684 series. It's also possible that a quote operator such as "qx//" could
685 have a corresponding function name like "quote:qx" that could be
686 invoked as a function.
687 RFC 222: Interpolation of Object Method Calls
689 I've been hankering for methods to interpolate for a long time, so I'm
691 in favor of this RFC. And it'll become doubly important as we move
692 toward encouraging people to use accessor methods to refer to object
693 attributes outside the class itself.
694 I have one "but," however. Since we'll switch to using "." instead of
696 "->", I think for sanity's sake we may have to require the parentheses,
697 or ""$file.$ext"" is going to give people fits. Not to mention
698 ""$file.ext"".
699 [Update: Nowadays we also require brackets on array interpolations and
701 braces on hash interpolations. See S3 for more.]
702 RFC 226: Selective Interpolation in Single Quotish Context.
704 This proposal has much going for it, but there are also difficulties,
706 and I've come close to rejecting it outright simply because the single-
707 quoting policy of Perl 5 has been successful. And I think the proposal
708 in this RFC for "\I"..."\E" is ugly. (And I'd like to kill "\E" anyway,
709 and use bracketed scopings.)
710 However, I think there is a major "can't get there from here" that we
712 could solve by treating interpolation into single quotes as something
713 hard, not something easy. The basic problem is that it's too easy to
714 run into a "\$" or "\@" (or a "\I" for that matter) that wants to be
715 taken literally. I think we could allow the interpolation of arbitrary
716 expressions into single-quoted strings, but only if we limit it to an
717 unlikely sequence where three or more characters are necessary for
718 recognition. The most efficient mental model would seem to be the idea
719 of embedding one kind of quote in another, so I think this:
720 \q{stuff}
722 will embed single-quoted stuff, while this:
724 \qq{stuff}
726 will embed double-quoted stuff. A variable could then be interpolated
728 into a single-quoted string by saying:
729 \qq{$foo}
731 RFC 237: Hashes Should Interpolate in Double-Quoted Strings
733 I agree with this RFC in principle, but we can't define the default
735 hash stringifier in terms of variables that are going away in Perl 6,
736 so the RFC's proposal of using $" is right out.
737 All objects should have a method by which they produce readable output.
739 How this may be overridden by user preference is open to debate. Cer‐
740 tainly, dynamic scoping has its problems. But lexical override of an
741 object's preferences is also problematic. Individual object properties
742 appear to give a decent way out of this. More on that below.
743 [Update: Hash values by default interpolate with tabs between key and
745 value, and with newline between pairs. But you can give it as specific
746 format with the ".as" method.]
747 On "printf" formats, I don't see any way to dwim that %d isn't an
749 array, so we'll just have to put formats into single quotes in general.
750 Those format strings that also interpolate variables will be able to
751 use the new "\qq{$var}" feature.
752 [Update: Since hash interpolations require braces now, "printf" formats
754 are safe again (unless they happen to be followed by curlies).]
755 Note for those who are thinking we should just stick with Perl 5 inter‐
757 polation rules: We have to allow "%" to introduce interpolation now
758 because individual hash values are no longer named with $foo{$bar}, but
759 rather %foo{$bar}. So we might as well allow interpolation of complete
760 hashes.
761 RFC 251: Interpolation of Class Method Calls
763 Class method calls are relatively rare (except for constructors, which
765 will be rarely interpolated). So rather than scanning for identifiers
766 that might introduce a class, I think we should just depend on expres‐
767 sion interpolation instead:
768 "There are $(Dog.numdogs) dogs."
770 [Update: That's now done with closure interpolation.]
772 RFC 252: Interpolation of Subroutines
774 I think subroutines should interpolate, provided they're introduced
776 with the funny character. (On the other hand, how hard is "$(sunset
777 $date)" or "@(sunset $date)"? On the gripping hand, I like the consis‐
778 tency of "&" with "$", "@" and "%".)
779 I think the parens are required, since in Perl 6, scalar &sub will just
781 return a reference, and require parens if you really want to deref the
782 sub ref. (It's true that a subroutine can be called without parens when
783 used as a list operator, but you can't interpolate those without a
784 funny character.)
785 For those worried about the use of "&" for signature checking suppres‐
787 sion, we should point out that "&" will no longer be the way to sup‐
788 press signature checking in Perl 6, so it doesn't matter.
789 RFC 327: "\v" for Vertical Tab
791 I think the opportunity cost of not reserving "\v" for future use is
793 too high to justify the small utility of retaining compatibility with a
794 feature virtually nobody uses anymore. For instance, I almost used "\v"
795 and "\V" for switching into and out of verbatim (single-quote) mode,
796 until I decided to unify that with quoting syntax and use "\qq{}" and
797 "\q{}" instead.
798 RFC 328: Single quotes don't interpolate \' and \\
800 I think hyperquotes will be possible with a declaration of your quoting
802 rules, so we're not going to change the basic single-quote rules
803 (except for supporting "\q").
804 [Update: There are adverbial modifiers now that can do hyperquoting.
806 See S2.]
807 Other Decisions About Literals
809 Scoping of \L et al.
811 I'd like to get rid of the gratuitously ugly "\E" as an end-of-scope
813 marker. Instead, if any sequence such as "\L", "\U" or "\Q" wishes to
814 impose a scope, then it must use curlies around that scope:
815 "\L{stuff}", "\U{stuff}" or "\Q{stuff}". Any literal curlies contained
816 in stuff must be backslashed. (Curlies as syntax (such as for sub‐
817 scripts) should nest correctly.)
818 [Update: Those constructs are now gone entirely. Use closure interpo‐
820 lation to interpolate the value of an expression.]
821 Bareword Policy
823 There will be no barewords in Perl 6. Any bare name that is a declared
825 package name will be interpreted as a class object that happens to
826 stringify to the package name. All other bare names will be interpreted
827 as subroutine or method calls. For nonstrict applications, undefined
828 subroutines will autodefine themselves to return their own name. Note
829 that in "${name}" and friends, the name is considered autoquoted, not a
830 bareword.
831 [Update: The "${name}" construct is gone. Use closure interpolation to
833 disambiguate expression interpolations: "{$name}text". The old brace
834 syntax is now reserved for hard dereferences only. Use "$::($name)"
835 for symbolic dereferences.]
836 Weird brackets
838 Use of brackets to disambiguate
840 "${foo[bar]}"
842 from
844 "${foo}[bar]"
846 will no longer be supported. Instead, the expression parser will always
848 grab as much as it can, and you can make it quit at a particular point
849 by interpolating a null string, specified by "\Q":
850 "$foo\Q[bar]"
852 [Update: That's gone too. Just use closure interpolation to disam‐
854 biguate.]
855 Special tokens
857 Special tokens will turn into either POD directives or lexically scoped
859 OO methods under the "MY" pseudo-package:
860 Old New
862 --- ---
863 __LINE__ MY.line
864 __FILE__ MY.file
865 __PACKAGE__ MY.package
866 __END__ =begin END (or remove)
867 __DATA__ =begin DATA
868 [Update: The first three are now "$?LINE", "$?FILE", and "$?PACKAGE".
870 There are other such variables too. See S2.]
871 Heredoc Syntax
873 I think heredocs will require quotes around any identifier, and we need
875 to be sure to support "<< qq(END)" style quotes. Space is now allowed
876 before the (required) quoted token. Note that custom quoting is now
877 possible, so if you define a fancy "qh" operator for your fancy hyper‐
878 quoting algorithm, then you could say "<<qh(END)".
879 It is still the case that you can say "<<""" to grab everything up to
881 the next blank line. However, Perl 6 will consider any line containing
882 only spaces, tabs, etc., to be blank, not just the ones that immedi‐
883 ately terminate with newline.
884
886 In Perl 5, a lot of contextual processing was done at run-time, and
887 even then, a given function could only discover whether it was in void,
888 scalar or list context. In Perl 6, we will extend the notion of context
889 to be more amenable to both compile-time and run-time analysis. In par‐
890 ticular, a function or method can know (theoretically even at compile
891 time) when it is being called in:
892 Void context
894 Scalar context
895 Boolean context
896 Integer context
897 Numeric context
898 String context
899 Object context
900 List context
901 Flattening list context (true list context).
902 Non-flattening list context (list of scalars/objects)
903 Lazy list context (list of closures)
904 Hash list context (list of pairs)
905 (This list isn't necessarily exhaustive.)
907 Each of these contexts (except maybe void) corresponds to a way in
909 which you might declare the parameters of a function (or the left side
910 of a list assignment) to supply context to the actual argument list (or
911 right side of a list assignment). By default, parameters will supply
912 object context, meaning individual parameters expect to be aliases to
913 the actual parameters, and even arrays and hashes don't do list context
914 unless you explicitly declare them to. These aren't cast in stone yet
915 (or even Jello), but here are some ideas for possible parameter decla‐
916 rations corresponding to those contexts:
917 Scalar context
919 Boolean context bit $arg
920 Integer context int $arg
921 Numeric context num $arg
922 String context str $arg
923 Object context $scalar, %hash, Dog @canines, &foo
924 List context
925 Flattening list context *@args
926 Non-flattening list context $@args
927 Lazy list context &@args
928 Hash list context *%args
929 [Update: Some of these are bogus. See S6 for the most recent formula‐
931 tion.]
932 (I also expect unary * to force flattening of arrays in rvalue con‐
934 texts. This is how we defeat the type signature in Perl 6, instead of
935 relying on the initial ampersand. So instead of Perl 5's
936 "&push(@list)", you could just say "push *@list", and it wouldn't mat‐
937 ter what "push"'s parameter signature said.)
938 It's also possible to define properties to modify formal arguments,
940 though that can get clunky pretty quickly, and I'd like to have a con‐
941 cise syntax for the common cases, such as the last parameter slurping a
942 list in the customary fashion. So the signature for the built-in "push"
943 could be
944 sub push (@array, *@pushees);
946 Actually, the signature might just be "(*@pushees)", if "push" is
948 really a method in the "ARRAY" class, and the object is passed implic‐
949 itly:
950 class ARRAY;
952 sub .push (*@pushees);
953 sub .pop (;int $numtopop);
954 sub .splice (int $offset, int $len, *@repl);
955 But we're getting ahead of ourselves.
957 [Update: Indeed, methods are declared with a "method" keyword, and
959 without the dot. Also the built-in class is "Array", not "ARRAY". See
960 A12 and S12 for much more about classes and methods.]
961 By the way, all function and method parameters (other than the object
963 itself) will be considered read-only unless declared with the "rw"
964 property. (List assignments will default the other way.) This will pre‐
965 vent a great deal of the wasted motion current Perl implementations
966 have to go through to make sure all function arguments are valid lval‐
967 ues, when most of them are in fact never modified.
968 Hmm, we're still getting ahead of ourselves. Back to contexts.
970 References are now transparent to boolean context
972 References are no longer considered to be "always true" in Perl 6. Any
974 type can overload its "bit()" casting operator, and any type that
975 hasn't got a "bit()" of its own inherits one from somewhere else, if
976 only from class UNIVERSAL. The built-in bit methods have the expected
977 boolean semantics for built-in types, so arrays are still true if they
978 have something in them, strings are true if they aren't "" or "0", etc.
979
981 RFC 175: Add "list" keyword to force list context (like "scalar")
982 Another RFC rescued from the compost pile. In Perl 6, type names will
984 identify casting functions in general. (A casting function merely
985 forces context -- it's a no-op unless the actual context is different.)
986 In Perl 6, a list used in a scalar context will automatically turn
987 itself into a reference to the list rather than returning the last ele‐
988 ment. (A subscript of "[-1]" can always be used to get the last element
989 explicitly, if that's actually desired. But that's a rarity, in prac‐
990 tice.) So it works out that the explicit list composer:
991 [1,2,3]
993 is syntactic sugar for something like:
995 scalar(list(1,2,3));
997 Depending on whether we continue to make a big deal of the list/array
999 distinction, that might actually be spelled:
1000 scalar(array(1,2,3));
1002 Other casts might be words like "hash" (supplying a pairlist context)
1004 and "objlist" (supplying a scalar context to a list of expressions).
1005 Maybe even the optional "sub" keyword could be considered a cast on a
1006 following block that might not otherwise be considered a closure in
1007 context. Perhaps "sub" is really spelled "lazy". In which case, we
1008 might even have a "lazylist" context to supply a lazy context to a list
1009 of expressions.
1010 [Update: Most of these aren't necessary. Just use the appropriate
1012 method.]
1013 And of course, you could use standard casts like "int()", "num()", and
1015 "str()", when you want to be explicit about such contexts at compile
1016 time. (Perl 5 already has these contexts, but only at run time.) Note
1017 also that, due to the relationship between unary functions and methods,
1018 "$foo.int", "$foo.num", and "$foo.str" will be just a different way to
1019 write the same casts.
1020 Lest you worry that your code is going to be full of casts, I should
1022 point out that you won't need to use these casts terribly often because
1023 each of these contexts will typically be implied by the signature of
1024 the function or method you're calling. (And Perl will still be autocon‐
1025 verting for you whenever it makes sense.) More on that in Apocalypse 6,
1026 Subroutines. If not sooner.
1027 So, while boolean context might be explicitly specified by writing:
1029 if (bit $foo)
1031 or
1033 if ($foo.bit)
1035 you'd usually just write it as in Perl 5:
1037 if ($foo)
1039 Other Decisions about Lists
1041 Based on some of what we've said, you can see that we'll have the abil‐
1043 ity to define various kinds of lazily generated lists. The specific
1044 design of these operators is left for subsequent Apocalypses, however.
1045 I will make one observation here, that I think some of the proposals
1046 for how array subscripts are generated should be generalized to work
1047 outside of subscripts as well. This may place some constraints on the
1048 general use of the ":" character in places where an operator is
1049 expected, for instance.
1050 [Update: And indeed, we now have adverbs that look like :foo(1).]
1052 As mentioned above, we'll be having several different kinds of list
1054 context. In particular, there will be a hash list context that assumes
1055 you're feeding it pairs, and if you don't feed it pairs, it will assume
1056 the value you feed it is a key, and supply a default value. There will
1057 likely be ways to get hashes to default to interesting values such as 0
1058 or 1.
1059 [Update: there isn't really a hash list context.]
1061 In order to do this, the "=>" operator has to at least mark its left
1063 operand as a key. More likely, it actually constructs a pair object in
1064 Perl 6. And the "{ foo => $bar }" list composer will be required to use
1065 "=>" (or be in a hashlist context), or it will instead be interpreted
1066 as a closure without a "sub". (You can always use an explicit "sub" or
1067 "hash" to cast the brackets to the proper interpretation.)
1068 I've noticed how many programs use "qw()" all over the place (much more
1070 frequently than the input operator, for instance), and I've always
1071 thought "qw()" was kind of ugly, so I'd like to replace it with some‐
1072 thing prettier. Since the input operator is using up a pair of per‐
1073 fectly good bracketing characters for little syntactic gain, we're
1074 going to steal those and make them into a qw-like list composer. In
1075 ordinary list context, the following would be identical:
1076 @list = < foo $bar %baz blurch($x) >;
1078 @list = qw/ foo $bar %baz blurch($x) /; # same as this
1079 @list = ('foo', '$bar', '%baz', 'blurch($x)'); # same as this
1080 But in hashlist context, it might be equivalent to this:
1082 %list = < foo $bar %baz blurch($x) >;
1084 %list = (foo => 1, '$bar' => 1, '%baz' = 1, blurch => $x); # same as this
1085 [Update: There is also a version with French quotes "«»" that does
1087 interpolation before splitting into words.]
1088
1090 Basically, file handles are just objects that can be used as iterators,
1091 and don't belong in this chapter anymore.
1092 RFC 034: Angle Brackets Should Not Be Used for File Globbing
1094 Indeed, they won't be. In fact, angle brackets won't be used for input
1096 at all, I suspect. See below. Er, above.
1097 [Update: Angle brackets don't directly do input. There is a unary "="
1099 that does the equivalent. For an argument it takes a filehandle,
1100 interator, filename, or list of any of those, and returns lines. There
1101 is a corresponding "lines" list operator.]
1102 RFC 051: Angle Brackets Should Accept Filenames and Lists
1104 There is likely to be no need for an explicit input operator in Perl 6,
1106 and I want the angles for something else. I/O handles are a subclass of
1107 iterators, and I think general iterator variables will serve the pur‐
1108 pose formerly served by the input operator, particularly since they can
1109 be made to do the right Thing in context. For instance, to read from
1110 standard input, it will suffice to say
1111 while ($STDIN) { ... }
1113 and the iterator will know it should assign to $_, because it's in a
1115 Boolean context.
1116 [Update: No, this confuses two different meanings of boolean. Use "for
1118 =$IN {...}" instead.]
1119 I read this RFC more as requesting a generic way to initialize an iter‐
1121 ator according to the type of the iterator. The trick in this case is
1122 to prevent the re-evaluation of the spec every time -- you don't want
1123 to reopen the file every time you read a line from it, for instance.
1124 There will be standard ways to suppress evaluation in Perl 6, both from
1125 the standpoint of the caller and the callee. In any case, the model is
1126 that an anonymous subroutine is passed in, and called only when appro‐
1127 priate. So an iterator syntax might prototype its argument to be an
1128 anonymous sub, or the user might explicitly pass an anonymous sub, or
1129 both. In any event, the "sub" keyword will be optional in Perl 6, so
1130 things like:
1131 while (file {LIST}) { ... }
1133 can be made to defer evaluation of LIST to the appropriate moment (or
1135 moments, if LIST is in turn generating itself on the fly). For appro‐
1136 priate parameter declarations I suppose even the brackets could be
1137 scrapped.
1138
1140 Variables and values of various types have various kinds of data
1141 attributes that are naturally associated with them by virtue of their
1142 type. You know a dog comes equipped with a wag, hopefully attached to a
1143 tail. That's just part of doghood.
1144 Many times, however, you want the equivalent of a Post-It(r) note, so
1146 you can temporarily attach bits of arbitrary information to some unsus‐
1147 pecting appliance that (though it wasn't designed for it) is neverthe‐
1148 less the right place to put the note. Similarly, variables and values
1149 in Perl 6 allow you to attach arbitrary pieces of information known as
1150 "properties." In essence, any object in Perl can have an associated
1151 hash containing these properties, which are named by the hash key.
1152 Some of these properties are known at compile time, and don't actually
1154 need to be stored with the object in question, but can actually be
1155 stored instead in the symbol table entry for the variable in question.
1156 (Perl still makes it appear as though these values are attached to the
1157 object.) Compile-time properties can therefore be attached to variables
1158 of any type.
1159 [Update: Compile-time properties are now known as "traits".]
1161 Run-time properties really are associated with the object in question,
1163 which implies some amount of overhead. For that reason, intrinsic data
1164 types like "int" and "num" may or may not allow run-time properties.
1165 In cases where it is allowed, the intrinsic type must generally be pro‐
1166 moted to its corresponding object type (or wrapped in an object that
1167 delegates back to the original intrinsic for the actual value). But you
1168 really don't want to promote an array of a million bits to an array of
1169 a million objects just because you had the hankering to put a sticky
1170 note on one of those bits, so in those cases it's likely to be disal‐
1171 lowed, or the bit is likely to be cloned instead of referenced, or some
1172 such thing.
1173 Properties may also be attached to subroutines.
1175 In general, you don't set or clear properties directly -- instead you
1177 call an accessor method to do it for you. If there is no method of that
1178 name, Perl will assume there was one that just sets or clears a prop‐
1179 erty with the same name as the method. However, using accessor methods
1180 to set or clear properties allows us to define synthetic properties.
1181 For instance, there might be a real "constant" property that you could
1182 attach to a variable. Certain variables (such as those in a function
1183 prototype) might have "constant" set by default. In that case, setting
1184 a synthetic property such as "rw" might clear the underlying "constant"
1185 property.
1186 A property may be attached to the foregoing expression by means of the
1188 "is" keyword. Here's a compile-time property set on a variable:
1189 my int $pi is constant = 3;
1191 Here's a run-time property set on a return value:
1193 return 0 is true;
1195 [Update: run-time properties are set with "but" rather than "is".]
1197 Whether a property is applied to a variable at compile time or a value
1199 at run-time depends on whether it's in lvalue or rvalue context.
1200 (Variable declarations are always in lvalue context even when you don't
1201 assign anything to them.)
1202 The ""is"" works just like the ""."" of a method call, except that the
1204 return value is the object on the left, not the return value of the
1205 method, which is discarded.
1206 As it happens, the ""is"" is optional in cases where an operator is
1208 already expected. So you might see things like:
1209 my int $pi constant = 3;
1211 return 0 true;
1212 In this case, the methods are actually being parsed as postfix opera‐
1214 tors. (However, we may make it a stricture that you may omit the "is"
1215 only for predeclared property methods.)
1216 [Update: the "is" or "but" is never optional.]
1218 Since these actually are method calls, you can pass arguments in addi‐
1220 tion to the object in question:
1221 my int @table is dim(366,24,60);
1223 [Update: that should be "@table[^366;^24;^60]" according to S9...]
1225 Our examples above are assuming an argument of "(1)":
1227 my int $pi is constant(1) = 3;
1229 return 0 is true(1);
1230 Since the ""is"" is optional in the common cases, you can stack multi‐
1232 ple properties without repeating the ""is"."
1233 my int $pi is shared locked constant optimize($optlevel) = 3;
1235 [Update: the "is" is no longer optional.]
1237 (Note that these methods are called on the $pi variable at compile
1239 time, so it behooves you to make sure everything you call is defined.
1240 For instance, $optlevel needs to be known at compile-time.)
1241 Here are a list of property ideas stolen from Damian. (I guess that
1243 makes it intellectual property theft.) Some of the names have been
1244 changed to protect the (CS) innocent.
1245 # Subroutine attributes...
1247 sub name is rw { ... } # was lvalue
1248 my sub rank is same { ... } # was memoized
1249 $snum = sub is optimize(1) { ... }; # "is" required here
1250 # Variable attributes...
1251 our $age is constant = 21; # was const
1252 my %stats is private;
1253 my int @table is dim(366,24,60);
1254 $arrayref = [1..1000000] is computed Purpose('demo of anon var attrs');
1255 sub choose_rand (@list is lazy) { return $list[rand @list] }
1256 # &@list notation is likely
1257 $self = $class.bless( {name=>$name, age=>$age} is Initialized );
1258 # Reference attributes...
1259 $circular = \$head is weak;
1260 # Literal attributes...
1261 $name = "Damian" is Note("test data only");
1262 $iohandle = open $filename is dis(qw/para crlf uni/) or die;
1263 $default = 42 is Meaning(<<OfLife);
1264 The Answer
1265 OfLife
1266 package Pet is interface;
1267 class Dog inherits('Canine') { ... }
1268 print $data{key is NoteToSelf('gotta get a better name for this key')};
1269 (I don't agree with using properties for all of these things, but it's
1271 pretty amazing how far into the ground you can drive it.)
1272 Property names should start with an identifier letter (which includes
1274 Unicode letters and ideographs). The parsing of the arguments (if any)
1275 is controlled by the signature of the method in question. Property
1276 method calls without a "." always modify their underlying property.
1277 [Update: the signature has nothing to do with how they're parsed. If a
1279 property has an argument it must follow without an intervening space.
1280 However, other brackets are allowed, and using "will" rather than "is"
1281 allows you to specify a closure with an intervening space.]
1282 If called as an ordinary method (with a "."), the property value is
1284 returned without being modified. That value could then be modified by a
1285 run-time property. For instance, "$pi.constant" would return 1 rather
1286 than the value of $pi, so we get:
1287 return $pi.constant is false; # "1 but false" (not possible in Perl 5)
1289 On the other hand, if you omit the dot, something else happens:
1291 return $pi constant is false; # 3 but false (and 3 is now very constant)
1293 [Update: The dot form is only for access of properties and traits that
1295 are already there.]
1296 Here are some more munged Damian examples:
1298 if (&name.rw) { ... }
1300 $age++ unless $age.constant;
1301 $elements = return reduce $^ * $^, *@table.dim;
1302 last if ${self}.Initialized;
1303 print "$arrayref.Purpose() is not $default.Meaning()\n";
1304 print %{$self.X}; # print hash referred to by X attribute of $self
1305 print %{$self}.X; # print X attribute of hash referred to by $self
1306 print %$self.X; # print X attribute of hash referred to by $self
1307 As with the dotless form, if there is no actual method corresponding to
1309 the property, Perl pretends there's a rudimentary one returning the
1310 actual property.
1311 [Update: Actually, they are real method calls now, and properties and
1313 traits are really mixins. See A12.]
1314 Since these methods return the properties (except when overridden by
1316 dotless syntax), you can temporize a property just as you can any
1317 method, provided the method itself allows writing:
1318 temp $self.X = 0;
1320 Note that
1322 temp $self is X = 0;
1324 would assign to 0 to $self instead. (Whether it actually makes sense to
1326 set the compile-time X property at run time on the $self variable is
1327 anybody's guess.)
1328 Note that by virtue of their syntax, properties cannot be set by inter‐
1330 polation into a string. So, happily:
1331 print "My $variable is foobar\n";
1333 does not attempt to set the "foobar" property on $variable.
1335 The ""is"" keyword binds with the same precedence as ".", even when
1337 it's not actually there.
1338 [Update: Actually, "but" now has the precedence of other non-chaining
1340 operators, such as "..". Since "is" occurs only in declarations, it is
1341 not subject to operator precedence at all.]
1342 Note that when you say "$foo.bar", you get $foo's compile-time property
1344 if there is one (which is known at compile time, duh). Otherwise it's
1345 an ordinary method call on the value (which looks for a run-time prop‐
1346 erty only if a method can't be found, so it shouldn't impact ordinary
1347 method call overhead.)
1348 [Update: No, that's always an ordinary method call now. Use "vari‐
1350 able($foo).bar" to get at a property of the variable, or to call any
1351 other method on the variable object rather than the referent of $foo.]
1352 To get to the properties directly without going through the method
1354 interface, use the special "btw" method, which returns a hash ref to
1355 the properties hash.
1356 $foo.btw{constant}
1358 Note that synthetic properties won't show up there!
1360 [Update: there is no such hash anymore, and synthetic properties are
1362 simply synthetic methods.]
1363 None of the property names in this Apocalypse should be taken as final.
1365 We will decide on actual property names as we proceed through the
1366 series.
1367 Well, that's it for Apocalypse 2. Doubtless there are some things I
1369 should have decided here that I didn't yet, but at least we're making
1370 progress. Well, at least we're moving in some direction or other. Now
1371 it's time for us to dance the Apocalypso, in honor of Jon Orwant and
1372 his new wife.
1373perl v5.8.8 2006-02-28 Perl6::Bible::A02(3)