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,
25 participants in the RFC process. (I beg special forgiveness from those
26 whose brains I haven't been able to get inside well enough to
27 incorporate their ideas). I would also like to particularly thank
28 Damian Conway, who will recognize many of his systematic ideas here,
29 including some 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
85 character sets behind the scenes. Note that when we say that Perl is
86 written in Unicode, we're speaking of an abstract character set, not
87 any 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
93 tender age by the rationale for the design of Ada, which made a good
94 case, I thought, for leaving multiline comments out of the language.
95 But even if I weren't blindly prejudiced, I suspect I'd look at the
97 psychology of the thing, and notice that much of the time, even in
98 languages that have multiline comments, people nevertheless tend to use
99 them like this:
100 /*
102 * Natter, natter, natter.
103 * Gromish, gromish, gromish.
104 */
105 The counterargument to that is, of course, that people don't always do
107 that in C, so why should they have to do it in Perl? And if there were
108 no other way to do multiline comments in Perl, they'd have a stronger
109 case. But there already is another way, albeit one rejected by this RFC
110 as "a workaround."
111 But it seems to me that, rather than adding another kind of comment or
113 trying to make something that looks like code behave like a comment,
114 the solution is simply to fix whatever is wrong with POD so that its
115 use for commenting can no longer be considered a workaround. Actual
116 design of POD can be put off till Apocalypse 26, but we can speculate
117 at this point that the rules for switching back and forth between POD
118 and Perl are suboptimal for use in comments. If so, then it's likely
119 that in Perl 6 we'll have a rule like this: If a "=begin MUMBLE"
120 transitions from Perl to POD mode then the corresponding "=end MUMBLE"
121 should transition back (without a "=cut" directive).
122 Note that we haven't defined our "MUMBLE"s yet, but they can be set up
124 to let our program have any sort of programmatic access to the data
125 that we desire. For instance, it is likely that comments of this kind
126 could be tied in with some sort of literate (or at least, semiliterate)
127 programming framework.
128 RFC 102: Inline Comments for Perl
130 I have never much liked inline comments -- as commonly practiced they
131 tend to obfuscate the code as much as they clarify it. That being said,
132 "All is fair if you predeclare." So there should be nothing preventing
133 someone from writing a lexer regex that handles them, provided we make
134 the lexer sufficiently mutable. Which we will. (As it happens, the
135 character sequence ""/*"" will be unlikely to occur in standard Perl 6.
136 Which I guess means it is likely to occur in nonstandard Perl 6. ":-)"
137 A pragma declaring nonstandard commenting would also allow people to
139 use "/* */" for multiline comments, if they like. (But I still think
140 it'd be better to use POD directives for that, just to keep the text
141 accessible to the program.)
142
144 The basic change here is that, rather than just supporting scalars,
145 arrays and hashes, Perl 6 supports opaque objects as a fourth
146 fundamental data type. (You might think of them as pseudo-hashes done
147 right.) While a class can access its object attributes any way it
148 likes, all external access to opaque objects occurs through methods,
149 even for attributes. (This guarantees that attribute inheritance works
150 correctly.)
151 While Perl 6 still defaults to typeless scalars, Perl will be able to
153 give you more performance and safety as you give it more type
154 information to work with. The basic assumption is that homogenous data
155 structures will be in arrays and hashes, so you can declare the type of
156 the scalars held in an array or hash. Heterogenous structures can still
157 be put into typeless arrays and hashes, but in general Perl 6 will
158 encourage you to use classes for such data, much as C encourages you to
159 use structs rather than arrays for such data.
160 One thing we'll be mentioning before we discuss it in detail is the
162 notion of "properties." (In Perl 5, we called these "attributes," but
163 we're reserving that term for actual object attributes these days, so
164 we'll call these things "properties.") Variables and values can have
165 additional data associated with them that is "out of band" with respect
166 to the ordinary typology of the variable or value. For now, just think
167 of properties as a way of adding ad hoc attributes to a class that
168 doesn't support them. You could also think of it as a form of class
169 derivation at the granularity of the individual object, without having
170 to declare a complete new class.
171 [Update: We're now calling compile-time properties "traits".]
173 RFC 161: Everything in Perl Becomes an Object.
175 This is essentially a philosophical RFC that is rather short on detail.
176 Nonetheless, I agree with the premise that all Perl objects should act
177 like objects if you choose to treat them that way. If you choose not to
178 treat them as objects, then Perl will try to go along with that, too.
179 (You may use hash subscripting and slicing syntax to call attribute
180 accessors, for instance, even if the attributes themselves are not
181 stored in a hash.) Just because Perl 6 is more object-oriented
182 internally, does not mean you'll be forced to think in object-oriented
183 terms when you don't want to. (By and large, there will be a few places
184 where OO-think is more required in Perl 6 than in Perl 5. Filehandles
185 are more object-oriented in Perl 6, for instance, and the special
186 variables that used to be magically associated with the currently
187 selected output handle are better specified by association with a
188 specific filehandle.)
189 RFC 038: Standardise Handling Of Abnormal Numbers Like Infinities and NaNs
191 This is likely to slow down numeric processing in some locations.
192 Perhaps it could be turned off when desirable. We need to be careful
193 not to invent something that is guaranteed to run slower than IEEE
194 floating point. We should also try to avoid defining a type system that
195 makes translation of numeric types to Java or C# types problematic.
196 That being said, standard semantics are a good thing, and should be the
198 default behavior.
199 RFC 043: Integrate BigInts (and BigRats) Support Tightly With the Basic
201 Scalars
202 This RFC suggests that a pragma enables the feature, but I think it
203 should probably be tied to the run-time type system, which means it's
204 driven more by how the data is created than by where it happens to be
205 stored or processed. I don't see how we can make it a pragma, except
206 perhaps to influence the meaning of "int" and "num" in actual
207 declarations further on in the lexical scope:
208 use bigint;
210 my int $i;
211 might really mean
213 my bigint $i;
215 or maybe just
217 my int $i is bigint;
219 since representation specifications might just be considered part of
221 the "fine print." But the whole subject of lexically scoped variable
222 properties specifying the nature of the objects they contain is a bit
223 problematic. A variable is a sort of mini-interface, a contract if you
224 will, between the program and the object in question. Properties that
225 merely influence how the program sees the object are not a problem --
226 when you declare a variable to be constant, you're promising not to
227 modify the object through that variable, rather than saying something
228 intrinsically true about the object. (Not that there aren't objects
229 that are intrinsically constant.)
230 Other property declarations might need to have some say in how
232 constructors are called in order to guarantee consistency between the
233 variable's view of the object, and the nature of the object itself. In
234 the worst case we could try to enforce consistency at run time, but
235 that's apt to be slow. If every assignment of a "Dog" object to a
236 "Mammal" variable has to check to see whether "Dog" is a "Mammal", then
237 the assignment is going to be a dog.
238 So we'll have to revisit this when we're defining the relationship
240 between variable declarations and constructors. In any event, if we
241 don't make Perl's numeric types automatically promote to big
242 representations, we should at least make it easy to specify it when you
243 want that to happen.
244 [Update: The "Int" type automatically upgrades to arbitrary precision
246 internally. The "int" type does not.]
247 RFC 192: Undef Values ne Value
249 I've rejected this one, because I think something that's undefined
250 should be considered just that, undefined. I think the standard
251 semantics are useful for catching many kinds of errors.
252 That being said, it'll hopefully be easy to modify the standard
254 operators within a particular scope, so I don't think we need to think
255 that our way to think is the only way to think, I think.
256 RFC 212: Make "length(@array)" Work
258 Here's an oddity, an RFC that the author retracted, but that I accept,
259 more or less. I think "length(@array)" should be equivalent to
260 "@array.length()", so if there's a "length" method available, it should
261 be called.
262 The question is whether there should be a "length" method at all, for
264 strings or arrays. It almost makes more sense for arrays than it does
265 for strings these days, because when you talk about the length of a
266 string, you need to know whether you're talking about byte length or
267 character length. So we may split up the traditional length function
268 into two, in which case we might end up with:
269 $foo.chars
271 $foo.bytes
272 @foo.elems
273 Or some such. Whatever the method names we choose, differentiating them
275 would be more powerful in supplying context. For instance, one could
276 envision calling "@foo.bytes" to return the byte length of all the
277 strings. That wouldn't fly if we overloaded the method name.
278 Even "chars($foo)" might not be sufficiently precise, since, depending
280 on how you're processing Unicode, you might want to know how long the
281 string is in actual characters, not counting combining characters that
282 don't take extra space. But that's a topic for later.
283 [Update: There is no "length" function. There are "bytes", "codes",
285 "graphs", and "langs" methods for the various Unicode support levels.
286 (The "chars" method returns one of those values depending on the
287 current Unicode support level.) Arrays and hashes report number of
288 elements with the "elems" method.]
289 RFC 218: "my Dog $spot" Is Just an Assertion
291 I expect that a declaration of the form:
292 my Dog $spot;
294 is merely an assertion that you will not use $spot inconsistently with
296 it being a "Dog". (But I mean something different by "assertion" than
297 this RFC does.) This assertion may or may not be tested at every
298 assignment to $spot, depending on pragmatic context. This bare
299 declaration does not call a constructor; however, there may be forms of
300 declaration that do. This may be necessary so that the variable and the
301 object can pass properties back and forth, and in general, make sure
302 they're consistent with each other. For example, you might declare an
303 array with a multidimensional shape, and this shape property needs to
304 be visible to the constructor, if we don't want to have to specify it
305 redundantly.
306 On the other hand, we might be able to get assignment sufficiently
308 overloaded to accomplish the same goal, so I'm deferring judgment on
309 that. All I'm deciding here is that a bare declaration without
310 arguments as above does not invoke a constructor, but merely tells the
311 compiler something.
312 [Update: The constructor may be called using the ".=new()" construct.]
314 Other Decisions About Types
316 Built-in object types will be in all uppercase: "INTEGER", "NUMBER",
317 "STRING", "REF", "SCALAR", "ARRAY", "HASH", "REGEX" and "CODE".
318 Corresponding to at least some of these, there will also be lowercase
319 intrinsic types, such as "int", "num", "str" and "ref". Use of the
320 lowercase typename implies you aren't intending to do anything fancy
321 OO-wise with the values, or store any run-time properties, and thus
322 Perl should feel free to store them compactly. (As a limiting case,
323 objects of type "bit" can be stored in one bit.) This distinction
324 corresponds roughly to the boxed/unboxed distinction of other computer
325 languages, but it is likely that Perl 6 will attempt to erase the
326 distinction for you to the extent possible. So, for instance, an "int"
327 may still be used in a string context, and Perl will convert it for
328 you, but it won't cache it, so the next time you use it as a string, it
329 will have to convert again.
330 [Update: The object types are no longer all caps, but "Int", "Num",
332 "Str", etc.]
333 The declared type of an array or hash specifies the type of each
335 element, not the type of an array or hash as a whole. This is justified
336 by the notion that an array or hash is really just a strange kind of
337 function that (typically) takes a subscript as an argument and returns
338 a value of a particular type. If you wish to associate a type with the
339 array or hash as a whole, that involves setting a "tie" property. If
340 you find yourself wishing to declare different types on different
341 elements, it probably means that you should either be using a class for
342 the whole heterogenous thing, or at least declare the type of array or
343 hash that will be a base class of all the objects it will contain.
344 Of course, untyped arrays and hashes will be just as acceptable as they
346 are currently. But a language can only run so fast when you force it to
347 defer all type checking and method lookup till run time.
348 The intent is to make use of type information where it's useful, and
350 not require it where it's not. Besides performance and safety, one
351 other place where type information is useful is in writing interfaces
352 to other languages. It is postulated that Perl 6 will provide enough
353 optional type declaration syntax that it will be unnecessary to write
354 XS-style glue in most cases.
355
357 RFC 071: Legacy Perl $pkg'var Should Die
358 I agree. I was unduly influenced by Ada syntax here, and it was a
359 mistake. And although we're adding a properties feature into Perl 6
360 that is much like Ada's attribute feature, we won't make the mistake of
361 reintroducing a syntax that drives highlighting editors nuts. We'll try
362 to make different mistakes this time.
363 RFC 009: Highlander Variable Types
365 I basically agree with the problem this RFC is trying to solve, but I
366 disagree with the proposed solution. The basic problem is that, while
367 the idiomatic association of $foo[$bar] with @foo rather than $foo
368 worked fine in Perl 4, when we added recursive data structures to Perl
369 5, it started getting in the way notationally, so that initial funny
370 character was trying to do too much in both introducing the "root" of
371 the reference, as well as the context to apply to the final subscript.
372 This necessitated odd looking constructions like:
373 $foo->[1][2][3]
375 This RFC proposes to solve the dilemma by unifying scalar variables
377 with arrays and hashes at the name level. But I think people like to
378 think of $foo, @foo and %foo as separate variables, so I don't want to
379 break that. Plus, the RFC doesn't unify &foo, while it's perfectly
380 possible to have a reference to a function as well as a reference to
381 the more ordinary data structures.
382 So rather than unifying the names, I believe all we have to do is unify
384 the treatment of variables with respect to references. That is, all
385 variables may be thought of as references, not just scalars. And in
386 that case, subscripts always dereference the reference implicit in the
387 array or hash named on the left.
388 This has two major implications, however. It means that Perl
390 programmers must learn to write @foo[1] where they used to write
391 $foo[1]. I think most Perl 5 people will be able to get used to this,
392 since many of them found the current syntax a bit weird in the first
393 place.
394 The second implication is that slicing needs a new notation, because
396 subscripts no longer have their scalar/list context controlled by the
397 initial funny character. Instead, the context of the subscript will
398 need to be controlled by some combination of:
399 1. Context of the entire term.
401 2. Appearance of known list operators in the subscript, such as comma
402 or range.
403 3. Explicit syntax casting the inside of the subscript to list or
404 scalar context.
405 4. Explicit declaration of default behavior.
406 One thing that probably shouldn't enter into it is the run-time type of
408 the array object, because context really needs to be calculated at
409 compile time if at all possible.
410 In any event, it's likely that some people will want subscripts to
412 default to scalars, and other people will want them to default to
413 lists. There are good arguments for either default, depending on
414 whether you think more like an APL programmer or a mere mortal.
415 [Update: Subscripts are always list context, but it's trivial to force
417 scalar context with either of the "+" or "~" unary operators.]
418 There are other larger implications. If composite variables are thought
420 of as scalar references, then the names @foo and %foo are really scalar
421 variables unless explicitly dereferenced. That means that when you
422 mention them in a scalar context, you get the equivalent of Perl 5's
423 "\@foo" and "\%foo". This simplifies the prototyping system greatly, in
424 that an operator like "push" no longer needs to specify some kind of
425 special reference context for its first argument -- it can merely
426 specify a scalar context, and that's good enough to assume the
427 reference generation on its first argument. (Of course, the function
428 signature can always be more specific if it wants to. More about that
429 in future installments.)
430 There are also implications for the assignment operator, in that it has
432 to be possible to assign array references to array variables without
433 accidentally invoking list context and copying the list instead of the
434 reference to the list. We could invent another assignment operator to
435 distinguish the two cases, but at the moment it looks as though bare
436 variables and slices will behave as lvalues just as they do in Perl 5,
437 while lists in parentheses will change to a binding of the right-hand
438 arguments more closely resembling the way Perl 6 will bind formal
439 arguments to actual arguments for function calls. That is to say,
440 @foo = (1,2,3);
442 will supply an unbounded list context to the right side, but
444 (@foo, @bar) = (@bar, @foo)
446 will supply a context to the right side that requests two scalar values
448 that are array references. This will be the default for unmarked
449 variables in an lvalue list, but there will be an easy way to mark
450 formal array and hash parameters to slurp the rest of the arguments
451 with list context, as they do by default in Perl 5.
452 (Alternately, we might end up leaving the ordinary list assignment
454 operator with Perl 5 semantics, and define a new assignment operator
455 such as ":=" that does signatured assignment. I can argue that one both
456 ways.)
457 [Update: We ended up with a ":=" binding operator.]
459 Just as arrays and hashes are explicitly dereferenced via subscripting
461 (or implicitly dereferenced in list context), so too functions are
462 merely named but not called by &foo, and explicitly dereferenced with
463 parentheses (or by use as a bare name without the ampersand (or both)).
464 The Perl 5 meanings of the ampersand are no longer in effect, in that
465 ampersand will no longer imply that signature matching is suppressed --
466 there will be a different mechanism for that. And since &foo without
467 parens doesn't do a call, it is no longer possible to use that syntax
468 to automatically pass the @_ array -- you'll have to do that explicitly
469 now with "foo(@_)".
470 Scalar variables are special, in that they may hold either references
472 or actual "native" values, and there is no special dereference syntax
473 as there is for other types. Perl 6 will attempt to hide the
474 distinction as much as possible. That is, if $foo contains a native
475 integer, calling the "$foo.bar" method will call a method on the built-
476 in type. But if $foo contains a reference to some other object, it will
477 call the method on that object. This is consistent with the way we
478 think about overloading in Perl 5, so you shouldn't find this behavior
479 surprising. It may take special syntax to get at any methods of the
480 reference variable itself in this case, but it's OK if special cases
481 are special.
482 RFC 133: Alternate Syntax for Variable Names
484 This RFC has a valid point, but in fact we're going to do just the
485 opposite of what it suggests. That is, we'll consider the funny
486 characters to be part of the name, and use the subscripts for context.
487 This works out better, because there's only one funny character, but
488 many possible forms of dereferencing.
489 RFC 134: Alternative Array and Hash Slicing
491 We're definitely killing Perl 5's slice syntax, at least as far as
492 relying on the initial character to determine the context of the
493 subscript. There are many ways we could reintroduce a slicing syntax,
494 some of which are mentioned in this RFC, but we'll defer the decision
495 on that till Apocalypse 9 on Data Structures, since the interesting
496 parts of designing slice syntax will be driven by the need to slice
497 multidimensional arrays.
498 [Update: There is no Apocalypse 9, but there is a Synopsis 9 that
500 covers these matters.]
501 For now we'll just say that arrays can have subscript signatures much
503 like functions have parameter signatures. Ordinary one-dimensional
504 arrays (and hashes) can then support some kind of simple slicing syntax
505 that can be extended for more complicated arrays, while allowing
506 multidimensional arrays to distinguish between simple slicing and
507 complicated mappings of lists and functions onto subscripts in a manner
508 more conducive to numerical programming.
509 On the subject of hash slices returning pairs rather than values, we
511 could distinguish this with special slice syntax, or we could establish
512 the notion of a hashlist context that tells the slice to return pairs
513 rather than just values. (We may not need a special slice syntax for
514 that if it's possible to typecast back and forth between pair lists and
515 ordinary lists.)
516 [Update: Slicing to get a pairlist can be done by attaching a ":p"
518 modifier to the subscript.]
519 RFC 196: More Direct Syntax for Hashes
521 This RFC makes three proposals, which we'll consider separately.
522 Proposal 1 is "that a hash in scalar context evaluate to the number of
524 keys in the hash." (You can find that out now, but only by using the
525 "keys()" function in scalar context.) Proposal 1 is OK if we change
526 "scalar context" to "numeric context," since in scalar context a hash
527 will produce a reference to the hash, which just happens to numify to
528 the number of entries.
529 We must also realize that some implementations of hash might have to go
531 through and count all the entries to return the actual number.
532 Fortunately, in boolean context, it suffices to find a single entry to
533 determine whether the hash contains anything. However, on hashes that
534 don't keep track of the number of entries, finding even one entry might
535 reset any active iterator on the hash, since some implementations of
536 hash (in particular, the ones that don't keep track of the number of
537 entries) may only supply a single iterator.
538 [Update: You may also call ".elems" to be more explicit.]
540 Proposal 2 is "that the iterator in a hash be reset through an explicit
542 call to the "reset()" function." That's fine, with the proviso that it
543 won't be a function, but rather a method on the HASH class.
544 Proposal 3 is really about "sort" recognizing pairs and doing the right
546 thing. Defaulting to sorting on $^a[0] cmp $^b[0] is likely to be
547 reasonable, and that's where a pair's key would be found. However, it's
548 probable that the correct solution is simply to provide a default
549 string method for anonymous lists that happens to produce a decent key
550 to sort on when "cmp" requests a string representation of either of its
551 arguments. The "sort" itself should probably just concentrate on
552 memoizing the returned strings so they don't have to be recalculated.
553 [Update: The "sort" interface has been completely revamped since this
555 was written. This will eventually appear in S29, but as of now it's
556 just in the perl6-language archives.]
557 RFC 201: Hash Slicing
559 This RFC proposes to use "%" as a marker for special hash slicing in
560 the subscript. Unfortunately, the "%" funny character will not be
561 available for this use, since all hash refs will start with "%".
562 Concise list comprehensions will require some other syntax within the
563 subscript, which will hopefully generalize to arrays as well.
564 Other Decisions About Variables
566 Various special punctuation variables are gone in Perl 6, including all
567 the deprecated ones. (Non-deprecated variables will be replaced by some
568 kind of similar functionality that is likely to be invoked through some
569 kind of method call on the appropriate object. If there is no
570 appropriate object, then a named global variable might provide similar
571 functionality.)
572 Freeing up the various bracketing characters allows us to use them for
574 other purposes, such as interpolation of expressions:
575 "$(expr)" # interpolate a scalar expression
577 "@(expr)" # interpolate a list expression
578 [Update: Those forms are gone now. Expression interpolation is done
580 via closure.]
581 $#foo is gone. If you want the final subscript of an array, and "[-1]"
583 isn't good enough, use "@foo.end" instead.
584 Other special variables (such as the regex variables) will change from
586 dynamic scoping to lexical scoping. It is likely that even $_ and @_
587 will be lexically scoped in Perl 6.
588
590 In Perl 5, lexical scopes are unnamed and unnameable. In Perl 6, the
591 current lexical scope will have a name that is visible within the
592 lexical scope as the pseudo class "MY", so that such a scope can, if it
593 so chooses, delegate management of its lexical scope to some other
594 module at compile time. In normal terms, that means that when you use a
595 module, you can let it import things lexically as well as packagely.
596 Typeglobs are gone. Instead, you can get at a variable object through
598 the symbol table hashes that are structured much like Perl 5's. The
599 variable object for $MyPackage::foo is stored in:
600 %MyPackage::{'$foo'}
602 Note that the funny character is part of the name. There is no longer
604 any structure in Perl that associates everything with the name ""foo"".
605 Perl's special global names are stored in a special package named ""*""
607 because they're logically in every scope that does not hide them. So
608 the unambiguous name of the standard input filehandle is $*STDIN, but a
609 package may just refer to $STDIN, and it will default to $*STDIN if no
610 package or lexical variable of that name has been declared.
611 [Update: We did s/STD// on those, so standard input is now just $*IN.]
613 Some of these special variables may actually be cloned for each lexical
615 scope or each thread, so just because a name is in the special global
616 symbol table doesn't mean it always behaves as a global across all
617 modules. In particular, changes to the symbol table that affect how the
618 parser works must be lexically scoped. Just because I install a special
619 rule for my cool new hyperquoting construct doesn't mean everyone else
620 should have to put up with it. In the limiting case, just because I
621 install a Python parser, it shouldn't force other modules into a maze
622 of twisty little whitespace, all alike.
623 Another way to look at it is that all names in the ""*"" package are
625 automatically exported to every package and/or outer lexical scope.
626
628 Underscores in Numeric Literals
629 Underscores will be allowed between any two digits within a number.
630 RFC 105: Remove "In string @ must be \@" Fatal Error
632 Fine.
633 [Update: The interpolation rules for arrays have been completely
635 revised. A bare array name no longer interpolates--you have to say
636 @foo[].]
637 RFC 111: Here Docs Terminators (Was Whitespace and Here Docs)
639 Fine.
640 RFC 162: Heredoc contents
642 I think I like option (e) the best: remove whitespace equivalent to the
643 terminator.
644 By default, if it has to dwim, it should dwim assuming that hard tabs
646 are 8 spaces wide. This should not generally pose a problem, since most
647 of the time the tabbing will be consistent throughout anyway, and no
648 dwimming will be necessary. This puts the onus on people using
649 nonstandard tabs to make sure they're consistent so that Perl doesn't
650 have to guess.
651 Any additional mangling can easily be accomplished by a user-defined
653 operator.
654 RFC 139: Allow Calling Any Function With a Syntax Like s///
656 Creative quoting will be allowed with lexical mutataion, but we can't
657 parse "foo(bar)" two different ways simultaneously, and I'm unwilling
658 to prevent people from using parens as quote characters. I don't see
659 how we can reasonably have new quote operators without explicit
660 declaration. And if the utility of a quote-like operator is sufficient,
661 there should be little relative burden in requiring such a declaration.
662 The form of such a declaration is left to the reader as an exercise in
664 function property definition. We may revisit the question later in this
665 series. It's also possible that a quote operator such as "qx//" could
666 have a corresponding function name like "quote:qx" that could be
667 invoked as a function.
668 RFC 222: Interpolation of Object Method Calls
670 I've been hankering for methods to interpolate for a long time, so I'm
671 in favor of this RFC. And it'll become doubly important as we move
672 toward encouraging people to use accessor methods to refer to object
673 attributes outside the class itself.
674 I have one "but," however. Since we'll switch to using "." instead of
676 "->", I think for sanity's sake we may have to require the parentheses,
677 or ""$file.$ext"" is going to give people fits. Not to mention
678 ""$file.ext"".
679 [Update: Nowadays we also require brackets on array interpolations and
681 braces on hash interpolations. See S3 for more.]
682 RFC 226: Selective Interpolation in Single Quotish Context.
684 This proposal has much going for it, but there are also difficulties,
685 and I've come close to rejecting it outright simply because the single-
686 quoting policy of Perl 5 has been successful. And I think the proposal
687 in this RFC for "\I"..."\E" is ugly. (And I'd like to kill "\E" anyway,
688 and use bracketed scopings.)
689 However, I think there is a major "can't get there from here" that we
691 could solve by treating interpolation into single quotes as something
692 hard, not something easy. The basic problem is that it's too easy to
693 run into a "\$" or "\@" (or a "\I" for that matter) that wants to be
694 taken literally. I think we could allow the interpolation of arbitrary
695 expressions into single-quoted strings, but only if we limit it to an
696 unlikely sequence where three or more characters are necessary for
697 recognition. The most efficient mental model would seem to be the idea
698 of embedding one kind of quote in another, so I think this:
699 \q{stuff}
701 will embed single-quoted stuff, while this:
703 \qq{stuff}
705 will embed double-quoted stuff. A variable could then be interpolated
707 into a single-quoted string by saying:
708 \qq{$foo}
710 RFC 237: Hashes Should Interpolate in Double-Quoted Strings
712 I agree with this RFC in principle, but we can't define the default
713 hash stringifier in terms of variables that are going away in Perl 6,
714 so the RFC's proposal of using $" is right out.
715 All objects should have a method by which they produce readable output.
717 How this may be overridden by user preference is open to debate.
718 Certainly, dynamic scoping has its problems. But lexical override of an
719 object's preferences is also problematic. Individual object properties
720 appear to give a decent way out of this. More on that below.
721 [Update: Hash values by default interpolate with tabs between key and
723 value, and with newline between pairs. But you can give it as specific
724 format with the ".as" method.]
725 On "printf" formats, I don't see any way to dwim that %d isn't an
727 array, so we'll just have to put formats into single quotes in general.
728 Those format strings that also interpolate variables will be able to
729 use the new "\qq{$var}" feature.
730 [Update: Since hash interpolations require braces now, "printf" formats
732 are safe again (unless they happen to be followed by curlies).]
733 Note for those who are thinking we should just stick with Perl 5
735 interpolation rules: We have to allow "%" to introduce interpolation
736 now because individual hash values are no longer named with $foo{$bar},
737 but rather %foo{$bar}. So we might as well allow interpolation of
738 complete hashes.
739 RFC 251: Interpolation of Class Method Calls
741 Class method calls are relatively rare (except for constructors, which
742 will be rarely interpolated). So rather than scanning for identifiers
743 that might introduce a class, I think we should just depend on
744 expression interpolation instead:
745 "There are $(Dog.numdogs) dogs."
747 [Update: That's now done with closure interpolation.]
749 RFC 252: Interpolation of Subroutines
751 I think subroutines should interpolate, provided they're introduced
752 with the funny character. (On the other hand, how hard is "$(sunset
753 $date)" or "@(sunset $date)"? On the gripping hand, I like the
754 consistency of "&" with "$", "@" and "%".)
755 I think the parens are required, since in Perl 6, scalar &sub will just
757 return a reference, and require parens if you really want to deref the
758 sub ref. (It's true that a subroutine can be called without parens when
759 used as a list operator, but you can't interpolate those without a
760 funny character.)
761 For those worried about the use of "&" for signature checking
763 suppression, we should point out that "&" will no longer be the way to
764 suppress signature checking in Perl 6, so it doesn't matter.
765 RFC 327: "\v" for Vertical Tab
767 I think the opportunity cost of not reserving "\v" for future use is
768 too high to justify the small utility of retaining compatibility with a
769 feature virtually nobody uses anymore. For instance, I almost used "\v"
770 and "\V" for switching into and out of verbatim (single-quote) mode,
771 until I decided to unify that with quoting syntax and use "\qq{}" and
772 "\q{}" instead.
773 RFC 328: Single quotes don't interpolate \' and \\
775 I think hyperquotes will be possible with a declaration of your quoting
776 rules, so we're not going to change the basic single-quote rules
777 (except for supporting "\q").
778 [Update: There are adverbial modifiers now that can do hyperquoting.
780 See S2.]
781 Other Decisions About Literals
783 Scoping of \L et al.
784 I'd like to get rid of the gratuitously ugly "\E" as an end-of-scope
786 marker. Instead, if any sequence such as "\L", "\U" or "\Q" wishes to
787 impose a scope, then it must use curlies around that scope:
788 "\L{stuff}", "\U{stuff}" or "\Q{stuff}". Any literal curlies contained
789 in stuff must be backslashed. (Curlies as syntax (such as for
790 subscripts) should nest correctly.)
791 [Update: Those constructs are now gone entirely. Use closure
793 interpolation to interpolate the value of an expression.]
794 Bareword Policy
796 There will be no barewords in Perl 6. Any bare name that is a declared
798 package name will be interpreted as a class object that happens to
799 stringify to the package name. All other bare names will be interpreted
800 as subroutine or method calls. For nonstrict applications, undefined
801 subroutines will autodefine themselves to return their own name. Note
802 that in "${name}" and friends, the name is considered autoquoted, not a
803 bareword.
804 [Update: The "${name}" construct is gone. Use closure interpolation to
806 disambiguate expression interpolations: "{$name}text". The old brace
807 syntax is now reserved for hard dereferences only. Use "$::($name)"
808 for symbolic dereferences.]
809 Weird brackets
811 Use of brackets to disambiguate
813 "${foo[bar]}"
815 from
817 "${foo}[bar]"
819 will no longer be supported. Instead, the expression parser will always
821 grab as much as it can, and you can make it quit at a particular point
822 by interpolating a null string, specified by "\Q":
823 "$foo\Q[bar]"
825 [Update: That's gone too. Just use closure interpolation to
827 disambiguate.]
828 Special tokens
830 Special tokens will turn into either POD directives or lexically scoped
832 OO methods under the "MY" pseudo-package:
833 Old New
835 --- ---
836 __LINE__ MY.line
837 __FILE__ MY.file
838 __PACKAGE__ MY.package
839 __END__ =begin END (or remove)
840 __DATA__ =begin DATA
841 [Update: The first three are now "$?LINE", "$?FILE", and "$?PACKAGE".
843 There are other such variables too. See S2.]
844 Heredoc Syntax
846 I think heredocs will require quotes around any identifier, and we need
848 to be sure to support "<< qq(END)" style quotes. Space is now allowed
849 before the (required) quoted token. Note that custom quoting is now
850 possible, so if you define a fancy "qh" operator for your fancy
851 hyperquoting algorithm, then you could say "<<qh(END)".
852 It is still the case that you can say "<<""" to grab everything up to
854 the next blank line. However, Perl 6 will consider any line containing
855 only spaces, tabs, etc., to be blank, not just the ones that
856 immediately terminate with newline.
857
859 In Perl 5, a lot of contextual processing was done at run-time, and
860 even then, a given function could only discover whether it was in void,
861 scalar or list context. In Perl 6, we will extend the notion of context
862 to be more amenable to both compile-time and run-time analysis. In
863 particular, a function or method can know (theoretically even at
864 compile time) when it is being called in:
865 Void context
867 Scalar context
868 Boolean context
869 Integer context
870 Numeric context
871 String context
872 Object context
873 List context
874 Flattening list context (true list context).
875 Non-flattening list context (list of scalars/objects)
876 Lazy list context (list of closures)
877 Hash list context (list of pairs)
878 (This list isn't necessarily exhaustive.)
880 Each of these contexts (except maybe void) corresponds to a way in
882 which you might declare the parameters of a function (or the left side
883 of a list assignment) to supply context to the actual argument list (or
884 right side of a list assignment). By default, parameters will supply
885 object context, meaning individual parameters expect to be aliases to
886 the actual parameters, and even arrays and hashes don't do list context
887 unless you explicitly declare them to. These aren't cast in stone yet
888 (or even Jello), but here are some ideas for possible parameter
889 declarations corresponding to those contexts:
890 Scalar context
892 Boolean context bit $arg
893 Integer context int $arg
894 Numeric context num $arg
895 String context str $arg
896 Object context $scalar, %hash, Dog @canines, &foo
897 List context
898 Flattening list context *@args
899 Non-flattening list context $@args
900 Lazy list context &@args
901 Hash list context *%args
902 [Update: Some of these are bogus. See S6 for the most recent
904 formulation.]
905 (I also expect unary * to force flattening of arrays in rvalue
907 contexts. This is how we defeat the type signature in Perl 6, instead
908 of relying on the initial ampersand. So instead of Perl 5's
909 "&push(@list)", you could just say "push *@list", and it wouldn't
910 matter what "push"'s parameter signature said.)
911 It's also possible to define properties to modify formal arguments,
913 though that can get clunky pretty quickly, and I'd like to have a
914 concise syntax for the common cases, such as the last parameter
915 slurping a list in the customary fashion. So the signature for the
916 built-in "push" could be
917 sub push (@array, *@pushees);
919 Actually, the signature might just be "(*@pushees)", if "push" is
921 really a method in the "ARRAY" class, and the object is passed
922 implicitly:
923 class ARRAY;
925 sub .push (*@pushees);
926 sub .pop (;int $numtopop);
927 sub .splice (int $offset, int $len, *@repl);
928 But we're getting ahead of ourselves.
930 [Update: Indeed, methods are declared with a "method" keyword, and
932 without the dot. Also the built-in class is "Array", not "ARRAY". See
933 A12 and S12 for much more about classes and methods.]
934 By the way, all function and method parameters (other than the object
936 itself) will be considered read-only unless declared with the "rw"
937 property. (List assignments will default the other way.) This will
938 prevent a great deal of the wasted motion current Perl implementations
939 have to go through to make sure all function arguments are valid
940 lvalues, when most of them are in fact never modified.
941 Hmm, we're still getting ahead of ourselves. Back to contexts.
943 References are now transparent to boolean context
945 References are no longer considered to be "always true" in Perl 6. Any
946 type can overload its "bit()" casting operator, and any type that
947 hasn't got a "bit()" of its own inherits one from somewhere else, if
948 only from class UNIVERSAL. The built-in bit methods have the expected
949 boolean semantics for built-in types, so arrays are still true if they
950 have something in them, strings are true if they aren't "" or "0", etc.
951
953 RFC 175: Add "list" keyword to force list context (like "scalar")
954 Another RFC rescued from the compost pile. In Perl 6, type names will
955 identify casting functions in general. (A casting function merely
956 forces context -- it's a no-op unless the actual context is different.)
957 In Perl 6, a list used in a scalar context will automatically turn
958 itself into a reference to the list rather than returning the last
959 element. (A subscript of "[-1]" can always be used to get the last
960 element explicitly, if that's actually desired. But that's a rarity, in
961 practice.) So it works out that the explicit list composer:
962 [1,2,3]
964 is syntactic sugar for something like:
966 scalar(list(1,2,3));
968 Depending on whether we continue to make a big deal of the list/array
970 distinction, that might actually be spelled:
971 scalar(array(1,2,3));
973 Other casts might be words like "hash" (supplying a pairlist context)
975 and "objlist" (supplying a scalar context to a list of expressions).
976 Maybe even the optional "sub" keyword could be considered a cast on a
977 following block that might not otherwise be considered a closure in
978 context. Perhaps "sub" is really spelled "lazy". In which case, we
979 might even have a "lazylist" context to supply a lazy context to a list
980 of expressions.
981 [Update: Most of these aren't necessary. Just use the appropriate
983 method.]
984 And of course, you could use standard casts like "int()", "num()", and
986 "str()", when you want to be explicit about such contexts at compile
987 time. (Perl 5 already has these contexts, but only at run time.) Note
988 also that, due to the relationship between unary functions and methods,
989 "$foo.int", "$foo.num", and "$foo.str" will be just a different way to
990 write the same casts.
991 Lest you worry that your code is going to be full of casts, I should
993 point out that you won't need to use these casts terribly often because
994 each of these contexts will typically be implied by the signature of
995 the function or method you're calling. (And Perl will still be
996 autoconverting for you whenever it makes sense.) More on that in
997 Apocalypse 6, Subroutines. If not sooner.
998 So, while boolean context might be explicitly specified by writing:
1000 if (bit $foo)
1002 or
1004 if ($foo.bit)
1006 you'd usually just write it as in Perl 5:
1008 if ($foo)
1010 Other Decisions about Lists
1012 Based on some of what we've said, you can see that we'll have the
1013 ability to define various kinds of lazily generated lists. The specific
1014 design of these operators is left for subsequent Apocalypses, however.
1015 I will make one observation here, that I think some of the proposals
1016 for how array subscripts are generated should be generalized to work
1017 outside of subscripts as well. This may place some constraints on the
1018 general use of the ":" character in places where an operator is
1019 expected, for instance.
1020 [Update: And indeed, we now have adverbs that look like :foo(1).]
1022 As mentioned above, we'll be having several different kinds of list
1024 context. In particular, there will be a hash list context that assumes
1025 you're feeding it pairs, and if you don't feed it pairs, it will assume
1026 the value you feed it is a key, and supply a default value. There will
1027 likely be ways to get hashes to default to interesting values such as 0
1028 or 1.
1029 [Update: there isn't really a hash list context.]
1031 In order to do this, the "=>" operator has to at least mark its left
1033 operand as a key. More likely, it actually constructs a pair object in
1034 Perl 6. And the "{ foo => $bar }" list composer will be required to use
1035 "=>" (or be in a hashlist context), or it will instead be interpreted
1036 as a closure without a "sub". (You can always use an explicit "sub" or
1037 "hash" to cast the brackets to the proper interpretation.)
1038 I've noticed how many programs use "qw()" all over the place (much more
1040 frequently than the input operator, for instance), and I've always
1041 thought "qw()" was kind of ugly, so I'd like to replace it with
1042 something prettier. Since the input operator is using up a pair of
1043 perfectly good bracketing characters for little syntactic gain, we're
1044 going to steal those and make them into a qw-like list composer. In
1045 ordinary list context, the following would be identical:
1046 @list = < foo $bar %baz blurch($x) >;
1048 @list = qw/ foo $bar %baz blurch($x) /; # same as this
1049 @list = ('foo', '$bar', '%baz', 'blurch($x)'); # same as this
1050 But in hashlist context, it might be equivalent to this:
1052 %list = < foo $bar %baz blurch($x) >;
1054 %list = (foo => 1, '$bar' => 1, '%baz' = 1, blurch => $x); # same as this
1055 [Update: There is also a version with French quotes "XX" that does
1057 interpolation before splitting into words.]
1058
1060 Basically, file handles are just objects that can be used as iterators,
1061 and don't belong in this chapter anymore.
1062 RFC 034: Angle Brackets Should Not Be Used for File Globbing
1064 Indeed, they won't be. In fact, angle brackets won't be used for input
1065 at all, I suspect. See below. Er, above.
1066 [Update: Angle brackets don't directly do input. There is a unary "="
1068 that does the equivalent. For an argument it takes a filehandle,
1069 interator, filename, or list of any of those, and returns lines. There
1070 is a corresponding "lines" list operator.]
1071 RFC 051: Angle Brackets Should Accept Filenames and Lists
1073 There is likely to be no need for an explicit input operator in Perl 6,
1074 and I want the angles for something else. I/O handles are a subclass of
1075 iterators, and I think general iterator variables will serve the
1076 purpose formerly served by the input operator, particularly since they
1077 can be made to do the right Thing in context. For instance, to read
1078 from standard input, it will suffice to say
1079 while ($STDIN) { ... }
1081 and the iterator will know it should assign to $_, because it's in a
1083 Boolean context.
1084 [Update: No, this confuses two different meanings of boolean. Use "for
1086 =$IN {...}" instead.]
1087 I read this RFC more as requesting a generic way to initialize an
1089 iterator according to the type of the iterator. The trick in this case
1090 is to prevent the re-evaluation of the spec every time -- you don't
1091 want to reopen the file every time you read a line from it, for
1092 instance. There will be standard ways to suppress evaluation in Perl 6,
1093 both from the standpoint of the caller and the callee. In any case, the
1094 model is that an anonymous subroutine is passed in, and called only
1095 when appropriate. So an iterator syntax might prototype its argument to
1096 be an anonymous sub, or the user might explicitly pass an anonymous
1097 sub, or both. In any event, the "sub" keyword will be optional in Perl
1098 6, so things like:
1099 while (file {LIST}) { ... }
1101 can be made to defer evaluation of LIST to the appropriate moment (or
1103 moments, if LIST is in turn generating itself on the fly). For
1104 appropriate parameter declarations I suppose even the brackets could be
1105 scrapped.
1106
1108 Variables and values of various types have various kinds of data
1109 attributes that are naturally associated with them by virtue of their
1110 type. You know a dog comes equipped with a wag, hopefully attached to a
1111 tail. That's just part of doghood.
1112 Many times, however, you want the equivalent of a Post-It(r) note, so
1114 you can temporarily attach bits of arbitrary information to some
1115 unsuspecting appliance that (though it wasn't designed for it) is
1116 nevertheless the right place to put the note. Similarly, variables and
1117 values in Perl 6 allow you to attach arbitrary pieces of information
1118 known as "properties." In essence, any object in Perl can have an
1119 associated hash containing these properties, which are named by the
1120 hash key.
1121 Some of these properties are known at compile time, and don't actually
1123 need to be stored with the object in question, but can actually be
1124 stored instead in the symbol table entry for the variable in question.
1125 (Perl still makes it appear as though these values are attached to the
1126 object.) Compile-time properties can therefore be attached to variables
1127 of any type.
1128 [Update: Compile-time properties are now known as "traits".]
1130 Run-time properties really are associated with the object in question,
1132 which implies some amount of overhead. For that reason, intrinsic data
1133 types like "int" and "num" may or may not allow run-time properties.
1134 In cases where it is allowed, the intrinsic type must generally be
1135 promoted to its corresponding object type (or wrapped in an object that
1136 delegates back to the original intrinsic for the actual value). But you
1137 really don't want to promote an array of a million bits to an array of
1138 a million objects just because you had the hankering to put a sticky
1139 note on one of those bits, so in those cases it's likely to be
1140 disallowed, or the bit is likely to be cloned instead of referenced, or
1141 some such thing.
1142 Properties may also be attached to subroutines.
1144 In general, you don't set or clear properties directly -- instead you
1146 call an accessor method to do it for you. If there is no method of that
1147 name, Perl will assume there was one that just sets or clears a
1148 property with the same name as the method. However, using accessor
1149 methods to set or clear properties allows us to define synthetic
1150 properties. For instance, there might be a real "constant" property
1151 that you could attach to a variable. Certain variables (such as those
1152 in a function prototype) might have "constant" set by default. In that
1153 case, setting a synthetic property such as "rw" might clear the
1154 underlying "constant" property.
1155 A property may be attached to the foregoing expression by means of the
1157 "is" keyword. Here's a compile-time property set on a variable:
1158 my int $pi is constant = 3;
1160 Here's a run-time property set on a return value:
1162 return 0 is true;
1164 [Update: run-time properties are set with "but" rather than "is".]
1166 Whether a property is applied to a variable at compile time or a value
1168 at run-time depends on whether it's in lvalue or rvalue context.
1169 (Variable declarations are always in lvalue context even when you don't
1170 assign anything to them.)
1171 The ""is"" works just like the ""."" of a method call, except that the
1173 return value is the object on the left, not the return value of the
1174 method, which is discarded.
1175 As it happens, the ""is"" is optional in cases where an operator is
1177 already expected. So you might see things like:
1178 my int $pi constant = 3;
1180 return 0 true;
1181 In this case, the methods are actually being parsed as postfix
1183 operators. (However, we may make it a stricture that you may omit the
1184 "is" only for predeclared property methods.)
1185 [Update: the "is" or "but" is never optional.]
1187 Since these actually are method calls, you can pass arguments in
1189 addition to the object in question:
1190 my int @table is dim(366,24,60);
1192 [Update: that should be "@table[^366;^24;^60]" according to S9...]
1194 Our examples above are assuming an argument of "(1)":
1196 my int $pi is constant(1) = 3;
1198 return 0 is true(1);
1199 Since the ""is"" is optional in the common cases, you can stack
1201 multiple properties without repeating the ""is"."
1202 my int $pi is shared locked constant optimize($optlevel) = 3;
1204 [Update: the "is" is no longer optional.]
1206 (Note that these methods are called on the $pi variable at compile
1208 time, so it behooves you to make sure everything you call is defined.
1209 For instance, $optlevel needs to be known at compile-time.)
1210 Here are a list of property ideas stolen from Damian. (I guess that
1212 makes it intellectual property theft.) Some of the names have been
1213 changed to protect the (CS) innocent.
1214 # Subroutine attributes...
1216 sub name is rw { ... } # was lvalue
1217 my sub rank is same { ... } # was memoized
1218 $snum = sub is optimize(1) { ... }; # "is" required here
1219 # Variable attributes...
1220 our $age is constant = 21; # was const
1221 my %stats is private;
1222 my int @table is dim(366,24,60);
1223 $arrayref = [1..1000000] is computed Purpose('demo of anon var attrs');
1224 sub choose_rand (@list is lazy) { return $list[rand @list] }
1225 # &@list notation is likely
1226 $self = $class.bless( {name=>$name, age=>$age} is Initialized );
1227 # Reference attributes...
1228 $circular = \$head is weak;
1229 # Literal attributes...
1230 $name = "Damian" is Note("test data only");
1231 $iohandle = open $filename is dis(qw/para crlf uni/) or die;
1232 $default = 42 is Meaning(<<OfLife);
1233 The Answer
1234 OfLife
1235 package Pet is interface;
1236 class Dog inherits('Canine') { ... }
1237 print $data{key is NoteToSelf('gotta get a better name for this key')};
1238 (I don't agree with using properties for all of these things, but it's
1240 pretty amazing how far into the ground you can drive it.)
1241 Property names should start with an identifier letter (which includes
1243 Unicode letters and ideographs). The parsing of the arguments (if any)
1244 is controlled by the signature of the method in question. Property
1245 method calls without a "." always modify their underlying property.
1246 [Update: the signature has nothing to do with how they're parsed. If a
1248 property has an argument it must follow without an intervening space.
1249 However, other brackets are allowed, and using "will" rather than "is"
1250 allows you to specify a closure with an intervening space.]
1251 If called as an ordinary method (with a "."), the property value is
1253 returned without being modified. That value could then be modified by a
1254 run-time property. For instance, "$pi.constant" would return 1 rather
1255 than the value of $pi, so we get:
1256 return $pi.constant is false; # "1 but false" (not possible in Perl 5)
1258 On the other hand, if you omit the dot, something else happens:
1260 return $pi constant is false; # 3 but false (and 3 is now very constant)
1262 [Update: The dot form is only for access of properties and traits that
1264 are already there.]
1265 Here are some more munged Damian examples:
1267 if (&name.rw) { ... }
1269 $age++ unless $age.constant;
1270 $elements = return reduce $^ * $^, *@table.dim;
1271 last if ${self}.Initialized;
1272 print "$arrayref.Purpose() is not $default.Meaning()\n";
1273 print %{$self.X}; # print hash referred to by X attribute of $self
1274 print %{$self}.X; # print X attribute of hash referred to by $self
1275 print %$self.X; # print X attribute of hash referred to by $self
1276 As with the dotless form, if there is no actual method corresponding to
1278 the property, Perl pretends there's a rudimentary one returning the
1279 actual property.
1280 [Update: Actually, they are real method calls now, and properties and
1282 traits are really mixins. See A12.]
1283 Since these methods return the properties (except when overridden by
1285 dotless syntax), you can temporize a property just as you can any
1286 method, provided the method itself allows writing:
1287 temp $self.X = 0;
1289 Note that
1291 temp $self is X = 0;
1293 would assign to 0 to $self instead. (Whether it actually makes sense to
1295 set the compile-time X property at run time on the $self variable is
1296 anybody's guess.)
1297 Note that by virtue of their syntax, properties cannot be set by
1299 interpolation into a string. So, happily:
1300 print "My $variable is foobar\n";
1302 does not attempt to set the "foobar" property on $variable.
1304 The ""is"" keyword binds with the same precedence as ".", even when
1306 it's not actually there.
1307 [Update: Actually, "but" now has the precedence of other non-chaining
1309 operators, such as "..". Since "is" occurs only in declarations, it is
1310 not subject to operator precedence at all.]
1311 Note that when you say "$foo.bar", you get $foo's compile-time property
1313 if there is one (which is known at compile time, duh). Otherwise it's
1314 an ordinary method call on the value (which looks for a run-time
1315 property only if a method can't be found, so it shouldn't impact
1316 ordinary method call overhead.)
1317 [Update: No, that's always an ordinary method call now. Use
1319 "variable($foo).bar" to get at a property of the variable, or to call
1320 any other method on the variable object rather than the referent of
1321 $foo.]
1322 To get to the properties directly without going through the method
1324 interface, use the special "btw" method, which returns a hash ref to
1325 the properties hash.
1326 $foo.btw{constant}
1328 Note that synthetic properties won't show up there!
1330 [Update: there is no such hash anymore, and synthetic properties are
1332 simply synthetic methods.]
1333 None of the property names in this Apocalypse should be taken as final.
1335 We will decide on actual property names as we proceed through the
1336 series.
1337 Well, that's it for Apocalypse 2. Doubtless there are some things I
1339 should have decided here that I didn't yet, but at least we're making
1340 progress. Well, at least we're moving in some direction or other. Now
1341 it's time for us to dance the Apocalypso, in honor of Jon Orwant and
1342 his new wife.
1343perl v5.12.0 2006-02-28 Perl6::Bible::A02(3)