Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Add a message at the top of most files that they are achived

  • Loading branch information...
1 parent ea91703 commit 5bc581559f50bc1385e3fbaede015527be1fa14a @ranguard ranguard committed
Showing with 25,331 additions and 50 deletions.
  1. +4 −0 source/archive/architecture.html
  2. +4 −0 source/archive/code.html
  3. +3 −0  source/archive/
  4. +3 −0  source/archive/doc/apocalypse.html
  5. +304 −0 source/archive/doc/design/apo/A01.html
  6. +1,138 −0 source/archive/doc/design/apo/A02.html
  7. +913 −0 source/archive/doc/design/apo/A03.html
  8. +2,054 −0 source/archive/doc/design/apo/A04.html
  9. +2,323 −0 source/archive/doc/design/apo/A05.html
  10. +3,564 −0 source/archive/doc/design/apo/A06.html
  11. +3,924 −0 source/archive/doc/design/apo/A12.html
  12. +607 −0 source/archive/doc/design/exe/E02.html
  13. +1,123 −0 source/archive/doc/design/exe/E03.html
  14. +1,396 −0 source/archive/doc/design/exe/E04.html
  15. +1,663 −0 source/archive/doc/design/exe/E05.html
  16. +2,072 −0 source/archive/doc/design/exe/E06.html
  17. +9 −0 source/archive/doc/design/syn/S01.html
  18. +9 −0 source/archive/doc/design/syn/S02.html
  19. +9 −0 source/archive/doc/design/syn/S03.html
  20. +9 −0 source/archive/doc/design/syn/S04.html
  21. +9 −0 source/archive/doc/design/syn/S05.html
  22. +9 −0 source/archive/doc/design/syn/S06.html
  23. +9 −0 source/archive/doc/design/syn/S09.html
  24. +9 −0 source/archive/doc/design/syn/S10.html
  25. +9 −0 source/archive/doc/design/syn/S11.html
  26. +9 −0 source/archive/doc/design/syn/S12.html
  27. +9 −0 source/archive/doc/design/syn/S13.html
  28. +9 −0 source/archive/doc/design/syn/S17.html
  29. +9 −0 source/archive/doc/design/syn/S29.html
  30. +3 −0  source/archive/doc/exegesis.html
  31. +108 −0 source/archive/faq.html
  32. +8 −50 source/archive/index.html
  33. +197 −0 source/archive/list-summaries/2002/p6summary.2002-06-23.html
  34. +176 −0 source/archive/list-summaries/2002/p6summary.2002-06-30.html
  35. +269 −0 source/archive/list-summaries/2002/p6summary.2002-07-07.html
  36. +332 −0 source/archive/list-summaries/2002/p6summary.2002-07-14.html
  37. +125 −0 source/archive/list-summaries/2002/p6summary.2002-07-21.html
  38. +235 −0 source/archive/list-summaries/2002/p6summary.2002-07-28.html
  39. +246 −0 source/archive/list-summaries/2002/p6summary.2002-08-04.html
  40. +374 −0 source/archive/list-summaries/2002/p6summary.2002-08-11.html
  41. +260 −0 source/archive/list-summaries/2002/p6summary.2002-08-18.html
  42. +449 −0 source/archive/list-summaries/2002/p6summary.2002-08-25.html
  43. +416 −0 source/archive/list-summaries/2002/p6summary.2002-09-01.html
  44. +428 −0 source/archive/list-summaries/2002/p6summary.2002-09-08.html
  45. +493 −0 source/archive/list-summaries/2002/p6summary.2002-09-15.html
  46. 0  source/archive/list-summaries/2002/p6summary.2002-09-22.html
  47. 0  source/archive/list-summaries/2002/p6summary.2002-09-29.html
  48. 0  source/archive/list-summaries/2002/p6summary.2002-10-20.html
  49. 0  source/archive/list-summaries/2002/p6summary.2002-10-27.html
  50. 0  source/archive/list-summaries/2002/p6summary.2002-11-03.html
  51. 0  source/archive/list-summaries/2002/p6summary.2002-11-10.html
  52. 0  source/archive/list-summaries/2002/p6summary.2002-11-17.html
  53. 0  source/archive/list-summaries/2002/p6summary.2002-11-24.html
  54. 0  source/archive/list-summaries/2002/p6summary.2002-12-01.html
  55. 0  source/archive/list-summaries/2002/p6summary.2002-12-08.html
  56. 0  source/archive/list-summaries/2002/p6summary.2002-12-15.html
  57. 0  source/archive/list-summaries/2002/p6summary.2002-12-22.html
  58. 0  source/archive/list-summaries/2002/p6summary.2002-12-29.html
  59. 0  source/archive/list-summaries/2003/p6summary.2003-01-05.html
  60. 0  source/archive/list-summaries/2003/p6summary.2003-01-12.html
  61. 0  source/archive/list-summaries/2003/p6summary.2003-01-19.html
  62. 0  source/archive/list-summaries/2003/p6summary.2003-01-26.html
  63. 0  source/archive/list-summaries/2003/p6summary.2003-02-02.html
  64. 0  source/archive/list-summaries/2003/p6summary.2003-02-09.html
  65. 0  source/archive/list-summaries/2003/p6summary.2003-02-16.html
  66. 0  source/archive/list-summaries/2003/p6summary.2003-02-23.html
  67. 0  source/archive/list-summaries/2003/p6summary.2003-03-02.html
  68. 0  source/archive/list-summaries/2003/p6summary.2003-03-09.html
  69. 0  source/archive/list-summaries/2003/p6summary.2003-03-16.html
  70. 0  source/archive/list-summaries/2003/p6summary.2003-03-23.html
  71. 0  source/archive/list-summaries/2003/p6summary.2003-03-30.html
  72. 0  source/archive/list-summaries/2003/p6summary.2003-04-06.html
  73. 0  source/archive/list-summaries/2003/p6summary.2003-04-13.html
  74. 0  source/archive/list-summaries/2003/p6summary.2003-04-20.html
  75. 0  source/archive/list-summaries/2003/p6summary.2003-04-27.html
  76. 0  source/archive/list-summaries/2003/p6summary.2003-05-04.html
  77. 0  source/archive/list-summaries/2003/p6summary.2003-05-11.html
  78. 0  source/archive/list-summaries/2003/p6summary.2003-05-18.html
  79. 0  source/archive/list-summaries/2003/p6summary.2003-05-25.html
  80. 0  source/archive/list-summaries/2003/p6summary.2003-06-01.html
  81. 0  source/archive/list-summaries/2003/p6summary.2003-06-08.html
  82. 0  source/archive/list-summaries/2003/p6summary.2003-06-15.html
  83. 0  source/archive/list-summaries/2003/p6summary.2003-06-22.html
  84. 0  source/archive/list-summaries/2003/p6summary.2003-06-29.html
  85. 0  source/archive/list-summaries/2003/p6summary.2003-07-06.html
  86. 0  source/archive/list-summaries/2003/p6summary.2003-07-13.html
  87. 0  source/archive/list-summaries/2003/p6summary.2003-07-20.html
  88. 0  source/archive/list-summaries/2003/p6summary.2003-07-27.html
  89. 0  source/archive/list-summaries/2003/p6summary.2003-08-03.html
  90. 0  source/archive/list-summaries/2003/p6summary.2003-08-10.html
  91. 0  source/archive/list-summaries/2003/p6summary.2003-08-17.html
  92. 0  source/archive/list-summaries/2003/p6summary.2003-08-24.html
  93. 0  source/archive/list-summaries/2003/p6summary.2003-08-31.html
  94. 0  source/archive/list-summaries/2003/p6summary.2003-09-07.html
  95. 0  source/archive/list-summaries/2003/p6summary.2003-09-14.html
  96. 0  source/archive/list-summaries/2003/p6summary.2003-09-21.html
  97. 0  source/archive/list-summaries/2003/p6summary.2003-09-28.html
  98. 0  source/archive/list-summaries/2003/p6summary.2003-10-05.html
  99. 0  source/archive/list-summaries/2003/p6summary.2003-10-12.html
  100. 0  source/archive/list-summaries/2003/p6summary.2003-10-19.html
  101. 0  source/archive/list-summaries/2003/p6summary.2003-10-26.html
  102. 0  source/archive/list-summaries/2003/p6summary.2003-11-02.html
  103. 0  source/archive/list-summaries/2003/p6summary.2003-11-09.html
  104. 0  source/archive/list-summaries/2003/p6summary.2003-11-16.html
  105. 0  source/archive/list-summaries/2003/p6summary.2003-11-23.html
  106. 0  source/archive/list-summaries/2003/p6summary.2003-11-30.html
  107. 0  source/archive/list-summaries/2003/p6summary.2003-12-07.html
  108. 0  source/archive/list-summaries/2003/p6summary.2003-12-14.html
  109. 0  source/archive/list-summaries/2003/p6summary.2003-12-21.html
  110. 0  source/archive/list-summaries/2003/p6summary.2003-12-28.html
  111. 0  source/archive/list-summaries/2004/p6summary.2004-01-04.html
  112. 0  source/archive/list-summaries/2004/p6summary.2004-01-11.html
  113. 0  source/archive/list-summaries/2004/p6summary.2004-01-18.html
  114. 0  source/archive/list-summaries/2004/p6summary.2004-01-25.html
  115. 0  source/archive/list-summaries/2004/p6summary.2004-02-01.html
  116. 0  source/archive/list-summaries/2004/p6summary.2004-02-08.html
  117. 0  source/archive/list-summaries/2004/p6summary.2004-02-15.html
  118. 0  source/archive/list-summaries/2004/p6summary.2004-02-22.html
  119. 0  source/archive/list-summaries/2004/p6summary.2004-02-29.html
  120. 0  source/archive/list-summaries/2004/p6summary.2004-03-07.html
  121. 0  source/archive/list-summaries/2004/p6summary.2004-03-14.html
  122. 0  source/archive/list-summaries/2004/p6summary.2004-03-21.html
  123. 0  source/archive/list-summaries/2004/p6summary.2004-03-28.html
  124. 0  source/archive/list-summaries/2004/p6summary.2004-04-04.html
  125. 0  source/archive/list-summaries/2004/p6summary.2004-04-18.html
  126. 0  source/archive/list-summaries/2004/p6summary.2004-04-25.html
  127. 0  source/archive/list-summaries/2004/p6summary.2004-05-02.html
  128. 0  source/archive/list-summaries/2004/p6summary.2004-05-09.html
  129. 0  source/archive/list-summaries/2004/p6summary.2004-05-23.html
  130. 0  source/archive/list-summaries/2004/p6summary.2004-06-06.html
  131. 0  source/archive/list-summaries/2004/p6summary.2004-06-21.html
  132. 0  source/archive/list-summaries/2004/p6summary.2004-06-27.html
  133. 0  source/archive/list-summaries/2004/p6summary.2004-07-04.html
  134. 0  source/archive/list-summaries/2004/p6summary.2004-07-10.html
  135. 0  source/archive/list-summaries/2004/p6summary.2004-07-18.html
  136. 0  source/archive/list-summaries/2004/p6summary.2004-07-25.html
  137. 0  source/archive/list-summaries/2004/p6summary.2004-07-31.html
  138. 0  source/archive/list-summaries/2004/p6summary.2004-08-06.html
  139. 0  source/archive/list-summaries/2004/p6summary.2004-08-20.html
  140. 0  source/archive/list-summaries/2004/p6summary.2004-08-27.html
  141. 0  source/archive/list-summaries/2004/p6summary.2004-09-03.html
  142. 0  source/archive/list-summaries/2004/p6summary.2004-09-10.html
  143. 0  source/archive/list-summaries/2004/p6summary.2004-09-17.html
  144. 0  source/archive/list-summaries/2004/p6summary.2004-09-24.html
  145. 0  source/archive/list-summaries/2004/p6summary.2004-10-17.html
  146. 0  source/archive/list-summaries/2004/p6summary.2004-10-23.html
  147. 0  source/archive/list-summaries/2004/p6summary.2004-11-01.html
  148. 0  source/archive/list-summaries/2004/p6summary.2004-11-08.html
  149. 0  source/archive/list-summaries/2004/p6summary.2004-11-15.html
  150. 0  source/archive/list-summaries/2004/p6summary.2004-11-22.html
  151. 0  source/archive/list-summaries/2004/p6summary.2004-11-29.html
  152. 0  source/archive/list-summaries/2004/p6summary.2004-12-06.html
  153. 0  source/archive/list-summaries/2004/p6summary.2004-12-20.html
  154. 0  source/archive/list-summaries/2005/p6summary.2005-01-03.html
  155. 0  source/archive/list-summaries/2005/p6summary.2005-01-11.html
  156. 0  source/archive/list-summaries/2005/p6summary.2005-01-18.html
  157. 0  source/archive/list-summaries/2005/p6summary.2005-01-31.html
  158. 0  source/archive/list-summaries/2005/p6summary.2005-02-08.html
  159. 0  source/archive/list-summaries/2005/p6summary.2005-02-22.html
  160. 0  source/archive/list-summaries/2005/p6summary.2005-03-07.html
  161. 0  source/archive/list-summaries/2005/p6summary.2005-03-22.html
  162. 0  source/archive/list-summaries/2005/p6summary.2005-04-05.html
  163. 0  source/archive/list-summaries/2005/p6summary.2005-04-12.html
  164. 0  source/archive/list-summaries/2005/p6summary.2005-04-19.html
  165. 0  source/archive/list-summaries/2005/p6summary.2005-04-26.html
  166. 0  source/archive/list-summaries/2005/p6summary.2005-05-03.html
  167. 0  source/archive/list-summaries/2005/p6summary.2005-05-18.html
  168. 0  source/archive/list-summaries/2005/p6summary.2005-05-24.html
  169. 0  source/archive/list-summaries/2005/p6summary.2005-05-31.html
  170. 0  source/archive/list-summaries/2005/p6summary.2005-06-07.html
  171. 0  source/archive/list-summaries/2005/p6summary.2005-06-21.html
  172. 0  source/archive/list-summaries/2005/p6summary.2005-06-28.html
  173. 0  source/archive/list-summaries/2005/p6summary.2005-07-05.html
  174. 0  source/archive/list-summaries/2005/p6summary.2005-07-12.html
  175. 0  source/archive/list-summaries/2005/p6summary.2005-07-19.html
  176. 0  source/archive/list-summaries/2005/p6summary.2005-07-26.html
  177. 0  source/archive/list-summaries/2005/p6summary.2005-08-02.html
  178. 0  source/archive/list-summaries/2005/p6summary.2005-08-10.html
  179. 0  source/archive/list-summaries/2005/p6summary.2005-08-14.html
  180. 0  source/archive/list-summaries/2005/p6summary.2005-08-22.html
  181. 0  source/archive/list-summaries/2005/p6summary.2005-09-11.html
  182. 0  source/archive/list-summaries/2005/p6summary.2005-09-19.html
  183. 0  source/archive/list-summaries/2005/p6summary.2005-09-25.html
  184. 0  source/archive/list-summaries/2005/p6summary.2005-10-02.html
  185. 0  source/archive/list-summaries/2005/p6summary.2005-10-09.html
  186. 0  source/archive/list-summaries/2005/p6summary.2005-10-25.html
  187. 0  source/archive/list-summaries/2005/p6summary.2005-10-30.html
  188. 0  source/archive/list-summaries/2005/p6summary.2005-11-13.html
  189. 0  source/archive/list-summaries/2005/p6summary.2005-11-21.html
  190. 0  source/archive/list-summaries/2005/p6summary.2005-11-27.html
  191. 0  source/archive/list-summaries/2005/p6summary.2005-12-04.html
  192. 0  source/archive/list-summaries/2005/p6summary.2005-12-12.html
  193. 0  source/archive/list-summaries/2005/p6summary.2005-12-18.html
  194. 0  source/archive/list-summaries/2006/p6summary.2006-01-01.html
  195. 0  source/archive/list-summaries/2006/p6summary.2006-01-11.html
  196. 0  source/archive/list-summaries/2006/p6summary.2006-01-24.html
  197. 0  source/archive/list-summaries/2006/p6summary.2006-02-07.html
  198. 0  source/archive/list-summaries/2006/p6summary.2006-02-12.html
  199. 0  source/archive/list-summaries/index.html
  200. 0  source/archive/lists/faq.html
  201. 0  source/archive/lists/historical.html
  202. 0  source/archive/lists/index.html
  203. 0  source/archive/lists/working-groups.html
  204. 0  source/archive/pdd/index.html
  205. 0  source/archive/pdd/pdd00_pdd.html
  206. 0  source/archive/pdd/pdd01_overview.html
  207. 0  source/archive/pdd/pdd02_vtables.html
  208. 0  source/archive/pdd/pdd03_calling_conventions.html
  209. 0  source/archive/pdd/pdd04_datatypes.html
  210. 0  source/archive/pdd/pdd05_opfunc.html
  211. 0  source/archive/pdd/pdd06_pasm.html
  212. 0  source/archive/pdd/pdd07_codingstd.html
  213. 0  source/archive/pdd/pdd08_keys.html
  214. 0  source/archive/pdd/pdd09_gc.html
  215. 0  source/archive/pdd/pdd10_embedding.html
  216. 0  source/archive/pdd/pdd11_extending.html
  217. 0  source/archive/pdd/pdd12_assembly.html
  218. 0  source/archive/pdd/pdd13_bytecode.html
  219. 0  source/archive/pdd/pdd14_bignum.html
  220. 0  source/archive/pdd/pdd15_objects.html
  221. 0  source/archive/pdd/pdd16_native_call.html
  222. 0  source/archive/pdd/pdd17_basic_types.html
  223. 0  source/archive/pdd/pdd18_security.html
  224. 0  source/archive/pdd/pdd_template.html
  225. 0  source/archive/people.html
  226. 0  source/archive/rfc/0.html
  227. 0  source/archive/rfc/1.html
  228. 0  source/archive/rfc/10.html
  229. 0  source/archive/rfc/100.html
  230. 0  source/archive/rfc/101.html
  231. 0  source/archive/rfc/102.html
  232. 0  source/archive/rfc/103.html
  233. 0  source/archive/rfc/104.html
  234. 0  source/archive/rfc/105.html
  235. 0  source/archive/rfc/106.html
  236. 0  source/archive/rfc/107.html
  237. 0  source/archive/rfc/108.html
  238. 0  source/archive/rfc/109.html
  239. 0  source/archive/rfc/11.html
  240. 0  source/archive/rfc/110.html
  241. 0  source/archive/rfc/111.html
  242. 0  source/archive/rfc/112.html
  243. 0  source/archive/rfc/113.html
  244. 0  source/archive/rfc/114.html
  245. 0  source/archive/rfc/115.html
  246. 0  source/archive/rfc/116.html
  247. 0  source/archive/rfc/117.html
  248. 0  source/archive/rfc/118.html
  249. 0  source/archive/rfc/119.html
  250. 0  source/archive/rfc/12.html
  251. 0  source/archive/rfc/120.html
  252. 0  source/archive/rfc/121.html
  253. 0  source/archive/rfc/122.html
  254. 0  source/archive/rfc/123.html
  255. 0  source/archive/rfc/124.html
  256. 0  source/archive/rfc/125.html
  257. 0  source/archive/rfc/126.html
  258. 0  source/archive/rfc/127.html
  259. 0  source/archive/rfc/128.html
  260. 0  source/archive/rfc/129.html
  261. 0  source/archive/rfc/13.html
  262. 0  source/archive/rfc/130.html
  263. 0  source/archive/rfc/131.html
  264. 0  source/archive/rfc/132.html
  265. 0  source/archive/rfc/133.html
  266. 0  source/archive/rfc/134.html
  267. 0  source/archive/rfc/135.html
  268. 0  source/archive/rfc/136.html
  269. 0  source/archive/rfc/137.html
  270. 0  source/archive/rfc/138.html
  271. 0  source/archive/rfc/139.html
  272. 0  source/archive/rfc/14.html
  273. 0  source/archive/rfc/140.html
  274. 0  source/archive/rfc/141.html
  275. 0  source/archive/rfc/142.html
  276. 0  source/archive/rfc/143.html
  277. 0  source/archive/rfc/144.html
  278. 0  source/archive/rfc/145.html
  279. 0  source/archive/rfc/146.html
  280. 0  source/archive/rfc/147.html
  281. 0  source/archive/rfc/148.html
  282. 0  source/archive/rfc/149.html
  283. 0  source/archive/rfc/15.html
  284. 0  source/archive/rfc/150.html
  285. 0  source/archive/rfc/151.html
  286. 0  source/archive/rfc/152.html
  287. 0  source/archive/rfc/153.html
  288. 0  source/archive/rfc/154.html
  289. 0  source/archive/rfc/155.html
  290. 0  source/archive/rfc/156.html
  291. 0  source/archive/rfc/157.html
  292. 0  source/archive/rfc/158.html
  293. 0  source/archive/rfc/159.html
  294. 0  source/archive/rfc/16.html
  295. 0  source/archive/rfc/160.html
  296. 0  source/archive/rfc/161.html
  297. 0  source/archive/rfc/162.html
  298. 0  source/archive/rfc/163.html
  299. 0  source/archive/rfc/164.html
  300. 0  source/archive/rfc/165.html
Sorry, we could not display the entire diff because too many files (593) changed.
4 source/archive/architecture.html
@@ -1,5 +1,9 @@
[% setvar title = "Perl6 Architecture" %]
+<h3>This file is part of the Archive</h3>
+<p>To see what is currently happening visit <a href=""></a></p>
Quick Summary</h2>
Source enters the parser. The parser emits a syntax tree.
4 source/archive/code.html
@@ -1,4 +1,8 @@
[% setvar title What is Parrot %]
+<h3>This file is part of the Archive</h3>
+<p>To see what is currently happening visit <a href=""></a></p>
What's Parrot
3  source/archive/
@@ -77,6 +77,9 @@
my $html = "[% setvar title $title %]\n";
+ $html .= '<h3>This file is part of the Perl 6 Archive</h3>
+ <p>To see what is currently happening visit <a href=""></a></p>
$html .= $podhtml->pod2html( $file, %pod_opts );
write_file( $html_file, $html );
3  source/archive/doc/apocalypse.html
@@ -1,5 +1,8 @@
[% setvar title = "Perl6 Apocalypses" %]
+<h3>This file is part of the Archive</h3>
+<p>To see what is currently happening visit <a href=""></a></p>
"What I will be revealing in these columns will be the design of Perl
6. Or more accurately, the beginnings of that design, since the design
304 source/archive/doc/design/apo/A01.html
@@ -0,0 +1,304 @@
+[% setvar title Apocalypse 1: The Ugly, the Bad, and the Good %]
+<h3>This file is part of the Perl 6 Archive</h3>
+ <p>To see what is currently happening visit <a href=""></a></p>
+<div class='pod'>
+<pre>=encoding utf-8</pre>
+<a name='TITLE'></a><h1>TITLE</h1>
+<p>Apocalypse 1: The Ugly, the Bad, and the Good</p>
+<a name='AUTHOR'></a><h1>AUTHOR</h1>
+<p>Larry Wall &lt;<a href=''></a>&gt;</p>
+<a name='VERSION'></a><h1>VERSION</h1>
+<pre> Maintainer: Larry Wall &lt;<a href=''></a>&gt;
+ Date: 2 Apr 2001
+ Last Modified: 18 May 2006
+ Number: 1
+ Version: 3</pre>
+<p>People get scared when they hear the word Apocalypse, but here I mean
+it in the good sense: a Revealing. An Apocalypse is supposed to reveal
+good news to good people. (And if it also happens to reveal bad news to
+bad people, so be it. Just don't be bad.)</p>
+<p>What I will be revealing in these columns will be the design of Perl 6.
+Or more accurately, the beginnings of that design, since the design
+process will certainly continue after I've had my initial say in the
+matter. I'm not omniscient, rumors to the contrary notwithstanding.
+This job of playing God is a little too big for me. Nevertheless,
+someone has to do it, so I'll try my best to fake it. And I'll expect
+all of you to help me out with the process of creating history. We all
+have to do our bit with free will.</p>
+<p>If you look at the history of Perl 6 up to this point, you will see
+why this column is subtitled The Ugly, the Bad, and the Good. The RFC
+process of last year was ugly, in a good sense. It was a brainstorming
+process, and that means it was deliberately ugly--not in the sense
+of incivility, since the RFC process was in fact surprisingly civil,
+but in the sense that there was little coherent design to the
+suggestions in the RFCs. Frankly, the RFCs are all over the map,
+without actually covering the map. There are contradictory RFCs, and
+there are missing RFCs. Many of the RFCs propose real problems but go
+off at funny angles in trying to propose solutions. Many of them patch
+symptoms without curing the underlying ailments.</p>
+<p>I also discovered Larry's First Law of Language Redesign: Everyone
+wants the colon.</p>
+<p>That was the Ugly part. The Bad part was that I was supposed to take
+these RFCs and produce a coherent design in two weeks. I starting out
+thinking I could just classify the RFCs into the good, bad, and ugly
+categories, but somehow most of them ended up in the ugly category,
+because the good ones typically had something wrong with them, and the
+even the bad ones typically indicated a problem that could use some
+thought, even if the solution was totally bogus.</p>
+<p>It is now five months later, and I've been mulling over coherence the
+whole time, for some definition of mulling. Many of you know what
+happens when the size of your Perl process exceeds the size of your
+physical memory--you start thrashing. Well, that's basically what
+happened to me. I couldn't get enough of the problem into my head at
+once to make good progress, and I'm not actually very good at
+subdividing problems. My forte is synthesis, not analysis. It didn't
+help that I had a number of distractions in my life, some of them
+self-inflicted, and some of them not. I won't go into all that. Save it
+for my unauthorized autobiography.</p>
+<p>But now we come to the Good part. (I hope.) After thinking lots and
+lots about many of the individual RFCs, and not knowing how to start
+thinking about them as a whole, it occurred to me (finally!) that the
+proper order to think about things was, more or less, the order of the
+chapters in the Camel Book. That is, the Camel Book's order is designed
+to minimize forward references in the explanation of Perl, so
+considering Perl 6 in roughly the same order will tend to reduce the
+number of things that I have to decide before I've decided them.</p>
+<p>So I've merrily classified all the RFCs by chapter number, and they
+look much more manageable now. (I also restructured my email so that I
+can look at a slice of all the messages that ever talked about a
+particular RFC, regardless of which mailing list the message was on.
+That's also a big help.) I intend to produce one Apocalypse for each
+Chapter, so Apocalypse 1 corresponds to Chapter 1: An Overview of Perl.
+(Of course, in the book, the Overview is more like a small tutorial,
+not really a complete analysis of the philosophical underpinnings of
+Perl. Nevertheless, it was a convenient place to classify those RFCs
+that talk about Perl 6 on that level.)</p>
+<p>So today I'm talking about the following RFCs:</p>
+<pre> RFC PSA Title
+ --- --- -----
+ 16 bdb Keep default Perl free of constraints such as warnings and strict.
+ 26 ccb Named operators versus functions
+ 28 acc Perl should stay Perl.
+ 73 adb All Perl core functions should return objects
+ 141 abr This Is The Last Major Revision</pre>
+<p>The PSA rating stands for &quot;Problem, Solution, Acceptance&quot;. The
+problem and solution are graded on an a-f scale, and very often you'll
+find I grade the problem higher than the solution. The acceptance
+rating is one of</p>
+<pre> a Accepted wholeheartedly
+ b Accepted with a few &quot;buts&quot;
+ c Accepted with some major caveats
+ r Rejected</pre>
+<p>I might at some point add a &quot;d&quot; for Deferred, if I really think it's
+too soon to decide something.</p>
+<a name='RFC 141: This Is The Last Major Revision'></a><h2>RFC 141: This Is The Last Major Revision</h2>
+<p>I was initially inclined to accept this RFC, but decided to reject it
+on theological grounds. In apocalyptic literature, 7 is the number
+representing perfection, while 6 is the number representing
+imperfection. In fact, we probably wouldn't end up converging on a
+version number of <code>2*PI</code> as the RFC suggests, but rather on <code>6.6.6</code>,
+which would be rather unfortunate.</p>
+<p>So Perl 7 will be the last major revision. In fact, Perl 7 will be so
+perfect, it will need no revision at all. Perl 6 is merely the
+prototype for Perl 7. <code>:-)</code></p>
+<p>Actually, I agree with the underlying sentiment of the RFC--I only
+rejected it for the entertainment value. I want Perl to be a language
+that can continue to evolve to better fit the problems people want to
+solve with it. To that end, I have several design goals that will tend
+to be obscured if you just peruse the RFCs.</p>
+<p>First, Perl will support multiple syntaxes that map onto a single
+semantic model. Second, that single semantic model will in turn map to
+multiple platforms.</p>
+<p>Multiple syntaxes sound like an evil thing, but they're really
+necessary for the evolution of the language. To some extent we already
+have a multi-syntax model in Perl 5; every time you use a pragma or
+module, you are warping the language you're using. As long as it's
+clear from the declarations at the top of the module which version of
+the language you're using, this causes little problem.</p>
+<p>A particularly strong example of how support of multiple syntaxes will
+allow continued evolution is the migration from Perl 5 to Perl 6
+itself. See the discussion of RFC 16 below.</p>
+<p>Multiple backends are a necessity of the world we live in today. Perl 6
+must not be limited to running only on platforms that can be programmed
+in C. It must be able to run in other kinds of virtual machines, such
+as those supported by Java and C#.</p>
+<a name='RFC 28: Perl should stay Perl.'></a><h2>RFC 28: Perl should stay Perl.</h2>
+<p>It is my fond hope that those who are fond of Perl 5 will be fonder
+still of Perl 6. That being said, it's also my hope that Perl will
+continue trying to be all things to all people, because that's part of
+Perl too.</p>
+<p>While I accept the RFC in principle (that is, I don't intend to go
+raving mad), I have some major caveats with it, because I think it is
+needlessly fearful that any of several programming paradigms will
+&quot;take over&quot; the design. This is not going to happen. Part of what
+makes Perl Perl is that it is intentionally multi-paradigmatic. You
+might say that Perl allows you to be paradigmatic without being
+<p>The essence of Perl is really context sensitivity, not just to
+syntactic context, but also to semantic, pragmatic, and cultural
+context. This overall philosophy is not going to change in Perl 6,
+although specific context sensitivities may come and go. Some of the
+current context sensitivities actually prevent us from doing a better
+job of it in other areas. By intentionally breaking a few things, we
+can make Perl understand what we mean even better than it does now.</p>
+<p>As a specific example, there are various ways things could improve if
+we muster the courage to break the &quot;weird&quot; relationship between
+<code>@foo</code> and <code>$foo[]</code>. True, we'd lose the current slice notation (it
+can be replaced with something better, I expect). But by consistently
+treating <code>@foo</code> as an utterance that in scalar context returns an
+array reference, we can make subscripts always <i>take</i> an array
+reference, which among other things fixes the botch that in Perl 5
+requires us to distinguish <code>$foo[]</code> from <code>$foo-&gt;[]</code>. There will
+be more discussion of this in Apocalypse 2, when we'll dissect ideas
+like RFC 9: Highlander Variable Types.</p>
+<a name='RFC 16: Keep default Perl free of constraints such as warnings and strict.'></a><h2>RFC 16: Keep default Perl free of constraints such as warnings
+and strict.</h2>
+<p>I am of two minds about this debate--there are good arguments for
+both sides. And if you read through the discussions, all those
+arguments were forcefully made, repeatedly. The specific discussion
+centered around the issue of strictness, of course, but the title of
+the RFC claims a more general philosophical position, and so it ended
+up in this Apocalypse.</p>
+<p>I'll talk about strictness and warnings in a moment, and I'll also talk
+about constraints in general, but I'd like to take a detour through
+some more esoteric design issues first. To my mind, this RFC (and the
+ones it is reacting against), are examples of why some language
+designer like me has to be the one to judge them, because they're all
+right, and they're all wrong, simultaneously. Many of the RFCs stake
+out polar positions and defend them ably, but fail to point out
+possible areas of compromise. To be sure, it is right for an RFC to
+focus in on a particular area and not try to do everything. But because
+all these RFCs are written with (mostly) the design of Perl 5 in mind,
+they cannot synthesize compromise even where the design of Perl 6 will
+make it mandatory.</p>
+<p>To me, one of the overriding issues is whether it's possible to
+translate Perl 5 code into Perl 6 code. One particular place of concern
+is in the many one-liners embedded in shell scripts here and there.
+There's no really good way to translate those invocations, so requiring
+a new command line switch to set &quot;no strict&quot; is not going to fly.</p>
+<p>A closely related question is how Perl is going to recognize when it
+has accidentally been fed Perl 5 code rather than Perl 6 code. It would
+be rather bad to suddenly give working code a brand new set of
+semantics. The answer, I believe, is that it has to be impossible by
+definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6
+must assume it is being fed Perl 5 code until it knows otherwise. And
+that implies that we must have some declaration that unambiguously
+declares the code to be Perl 6.</p>
+<p>Now, there are right ways to do this, and wrong ways. I was peeved by
+the approach taken by DEC when they upgraded BASIC/PLUS to handle long
+variable names. Their solution was to require every program using long
+variable names to use the command <code>EXTEND</code> at the top. So henceforth
+and forevermore, every BASIC/PLUS program had <code>EXTEND</code> at the top of
+it. I don't know whether to call it Bad or Ugly, but it certainly
+wasn't Good.</p>
+<p>A better approach is to modify something that would have to be there
+anyway. If you go out to CPAN and look at every single module out
+there, what do you see at the top? Answer: a &quot;<code>package</code>&quot;
+declaration. So we break that.</p>
+<p>I hereby declare that a <code>package</code> declaration at the front of a file
+unambiguously indicates you are parsing Perl 5 code. If you want to
+write a Perl 6 module or class, it'll start with the keyword <code>module</code>
+or <code>class</code>. I don't know yet what the exact syntax of a module or a
+class declaration will be, but one thing I do know is that it'll set
+the current global namespace much like a <code>package</code> declaration does.</p>
+<p>Now with one fell swoop, much of the problem of programming in the
+large can be dealt with simply by making modules and classes default to
+strict, with warnings. But note that the default in the main program
+(and in one liners) is Perl 5, which is non-strict by definition. We
+still have to figure out how Perl 6 main programs should distinguish
+themselves from Perl 5 (with a &quot;<code>use 6.0</code>&quot; maybe?), and whether Perl
+6 main programs should default to strict or not (I think not), but you
+can already see that a course instructor could threaten to flunk anyone
+who doesn't put &quot;<code>module Main</code>&quot; at the front each program, and never
+actually tell their pupils that they want that because it turns on
+strictures and warnings.</p>
+<p>Other approaches are possible, but that leads us to a deeper issue,
+which is the issue of project policy and site policy. People are always
+hankering for various files to be automatically read in from various
+locations, and I've always steadfastly resisted that because it makes
+scripts implicitly non-portable. However, explicit non-portability is
+okay, so there's no reason our hypothetical class instructor could not
+insist that programs start with a &quot;<code>use Policy;</code>&quot; or some such.</p>
+<p>But now again we see how this leads to an even deeper language design
+issue. The real problem is that it's difficult to write such a Policy
+module in Perl 5, because it's really not a module but a meta-module.
+It wants to do &quot;<code>use strict</code>&quot; and &quot;<code>use warnings</code>&quot; on behalf of
+the student, but it cannot do so. Therefore one thing we must implement
+in Perl 6 is the ability to write meta-use statements that look like
+ordinary use statements but turn around and declare other things on
+behalf of the user, for the good of the user, or of the project, or of
+the site. (Whatever. I'm not a policy wonk.)</p>
+<p>So whether I agree with this RFC really depends on what it means by
+&quot;default&quot;. And like Humpty Dumpty, I'll just make it mean whatever I
+think is most convenient. That's context sensitivity at work.</p>
+<p>I also happen to agree with this RFC because it's my philosophical
+position that morality works best when chosen, not when mandated.
+Nevertheless, there are times when morality should be strongly
+suggested, and I think modules and classes are a good place for that.</p>
+<p>[Update: Nowadays the main program is also strict by default, as soon
+as we know it's Perl 6 and not Perl 5. If we say something like
+&quot;<code>use 6.0;</code>&quot; as the first thing, we know it's Perl 6, and thus we
+know it's strict. (Likewise saying <code>#!/usr/bin/perl6</code> would default
+to strict.) I think we could recognize a shorter, less formal
+form without the <code>use</code> which would default to not being strict:</p>
+<pre> v6;
+ $x = 1; # global is legal</pre>
+<p>(Without the <code>v6</code> it would default to Perl 5.) Scripts supplied
+with a <code>-e</code> would also not be strict. Of course, there's always
+&quot;<code>no strict</code>&quot;.]</p>
+<a name='RFC 73: All Perl core functions should return objects'></a><h2>RFC 73: All Perl core functions should return objects</h2>
+<p>I'm not sure this belongs in the overview, but here it is nonetheless.
+In principle, I agree with the RFC. Of course, if all Perl variables
+are really objects underneath, this RFC is trivially true. But the real
+question is how interesting of an object you can return for a given
+level of performance. Perl 5's objects are relatively heavyweight, and
+if all of Perl 6's objects are as heavy, things might bog down.</p>
+<p>I'm thinking that the solution is better abstract type support for data
+values that happen to be represented internally by C <code>struct</code>s. We get
+bogged down when we try to translate a C <code>struct</code> such a <code>struct tm</code>
+into an actual hash value. On the other hand, it's rather efficient to
+translate a <code>struct tm</code> to a <code>struct tm</code>, since it's a no-op. We can
+make such a <code>struct</code> look like a Perl object, and access it
+efficiently with attribute methods as if it were a &quot;real&quot; object. And
+the typology will (hopefully) mostly only impose an abstract overhead.
+The biggest overhead will likely be memory management of a <code>struct</code>
+over an <code>int</code> (say), and that overhead could go away much of the time
+with some amount of contextually aware optimization.</p>
+<p>In any event, I just want to point out that nobody should panic when we
+talk about making things return objects that didn't used to return
+them. Remember that any object can define its <code>stringify</code> and
+<code>numify</code> overloadings to do whatever the class likes, so old code that
+looks like</p>
+<pre> print scalar localtime;</pre>
+<p>can continue to run unchanged, even though <code>localtime</code> might be
+returning an object in scalar context.</p>
+<a name='RFC 26: Named operators versus functions'></a><h2>RFC 26: Named operators versus functions</h2>
+<p>Here's another RFC that's here because I couldn't think of a better
+place for it.</p>
+<p>I find this RFC somewhat confusing because the abstract seems to
+suggest something more radical than the description describes. If you
+ignore the abstract, I pretty much agree with it. It's already the case
+in Perl 5 that we distinguish operators from functions primarily by how
+they are called, not by how they are defined. One place where the RFC
+could be clarified is that Perl 5 distinguishes two classes of named
+operators: named unary operators vs list operators. They are
+distinguished because they have different precedence. We'll discuss
+precedence reform under Apocalypse 3, but I doubt we'll combine the two
+kinds of named operators. (As a teaser, I do see ways of simplifying
+Perl's precedence table from 24 levels down to 18 levels, albeit with
+some damage to C compatibility in the less frequently used ops. More on
+that later.)</p>
+<p>Do you begin to see why my self-appointed job here is much larger than
+just voting RFCs up or down? There are many big issues to face that
+simply aren't covered by the RFCs. We have to decide how much of our
+culture is just baggage to be thrown overboard, and how much of it is
+who we are. We have to smooth out the migration from Perl 5 to Perl 6
+to prevent people from using that as an excuse not to adopt Perl 6. And
+we have to stare at all those deep issues until we see through them
+down to the underlying deeper issues, and the issues below that. And
+then in our depths of understanding, we have to keep Perl simple enough
+for anyone to pick up and start using to get their job done right now.</p>
+<p>Stay tuned for Apocalypse 2, wherein we will attempt to vary our
+variables, question our quotes, recontextualize our contexts, and in
+general set the lexical stage for everything that follows.</p>
1,138 source/archive/doc/design/apo/A02.html
@@ -0,0 +1,1138 @@
+[% setvar title Apocalypse 2: Bits and Pieces %]
+<h3>This file is part of the Perl 6 Archive</h3>
+ <p>To see what is currently happening visit <a href=""></a></p>
+<div class='pod'>
+<pre>=encoding utf-8</pre>
+<a name='TITLE'></a><h1>TITLE</h1>
+<p>Apocalypse 2: Bits and Pieces</p>
+<a name='AUTHOR'></a><h1>AUTHOR</h1>
+<p>Larry Wall &lt;<a href=''></a>&gt;</p>
+<a name='VERSION'></a><h1>VERSION</h1>
+<pre> Maintainer: Larry Wall &lt;<a href=''></a>&gt;
+ Date: 3 May 2001
+ Last Modified: 18 May 2006
+ Number: 2
+ Version: 6</pre>
+<p>Here's Apocalypse 2, meant to be read in conjunction with Chapter 2 of
+the Camel Book. The basic assumption is that if Chapter 2 talks about
+something that I don't discuss here, it doesn't change in Perl 6. (Of
+course, it could always just be an oversight. One might say that people
+who oversee things have a gift of oversight.)</p>
+<p>Before I go further, I would like to thank all the victims, er,
+participants in the RFC process. (I beg special forgiveness from those
+whose brains I haven't been able to get inside well enough to
+incorporate their ideas). I would also like to particularly thank
+Damian Conway, who will recognize many of his systematic ideas here,
+including some that have been less than improved by my meddling.</p>
+<p>Here are the RFCs covered:</p>
+<pre> RFC PSA Title
+ --- --- -----
+ Textual
+ 005 cdr Multiline Comments for Perl
+ 102 dcr Inline Comments for Perl
+ Types
+ 161 adb Everything in Perl Becomes an Object
+ 038 bdb Standardise Handling of Abnormal Numbers Like Infinities and NaNs
+ 043 bcb Integrate BigInts (and BigRats) Support Tightly With the Basic Scalars
+ 192 ddr Undef Values ne Value
+ 212 rrb Make Length(@array) Work
+ 218 bcc C&lt;my Dog $spot&gt; Is Just an Assertion
+ Variables
+ 071 aaa Legacy Perl $pkg'var Should Die
+ 009 bfr Highlander Variable Types
+ 133 bcr Alternate Syntax for Variable Names
+ 134 bcc Alternative Array and Hash Slicing
+ 196 bcb More Direct Syntax for Hashes
+ 201 bcr Hash Slicing
+ Strings
+ 105 aaa Remove &quot;In string @ must be \@&quot; Fatal Error
+ 111 aaa Here Docs Terminators (Was Whitespace and Here Docs)
+ 162 abb Heredoc Contents
+ 139 cfr Allow Calling Any Function With a Syntax Like s///
+ 222 abb Interpolation of Object Method Calls
+ 226 acr Selective Interpolation in Single Quotish Context
+ 237 adc Hashes Should Interpolate in Double-Quoted Strings
+ 251 acr Interpolation of Class Method Calls
+ 252 abb Interpolation of Subroutines
+ 327 dbr C&lt;\v&gt; for Vertical Tab
+ 328 bcr Single Quotes Don't Interpolate \' and \\
+ Files
+ 034 aaa Angle Brackets Should Not Be Used for File Globbing
+ 051 ccr Angle Brackets Should Accept Filenames and Lists
+ Lists
+ 175 rrb Add C&lt;list&gt; Keyword to Force List Context (like C&lt;scalar&gt;)
+ Retracted
+ 010 rr Filehandles Should Use C&lt;*&gt; as a Type Prefix If Typeglobs Are Eliminated
+ 103 rr Fix C&lt;$pkg::$var&gt; Precedence Issues With Parsing of C&lt;::&gt;
+ 109 rr Less Line Noise - Let's Get Rid of @%
+ 245 rr Add New C&lt;empty&gt; Keyword to DWIM for Clearing Values
+ 263 rr Add Null() Keyword and Fundamental Data Type</pre>
+<a name='Atoms'></a><h1>Atoms</h1>
+<p>Perl 6 programs are notionally written in Unicode, and assume Unicode
+semantics by default even when they happen to be processing other
+character sets behind the scenes. Note that when we say that Perl is
+written in Unicode, we're speaking of an abstract character set, not
+any particular encoding. (The typical program will likely be written in
+UTF-8 in the West, and in some 16-bit character set in the East.)</p>
+<a name='Molecules'></a><h1>Molecules</h1>
+<a name='RFC 005: Multiline Comments for Perl'></a><h2>RFC 005: Multiline Comments for Perl</h2>
+<p>I admit to being prejudiced on this one -- I was unduly influenced at a
+tender age by the rationale for the design of Ada, which made a good
+case, I thought, for leaving multiline comments out of the language.</p>
+<p>But even if I weren't blindly prejudiced, I suspect I'd look at the
+psychology of the thing, and notice that much of the time, even in
+languages that have multiline comments, people nevertheless tend to use
+them like this:</p>
+<pre> /*
+ * Natter, natter, natter.
+ * Gromish, gromish, gromish.
+ */</pre>
+<p>The counterargument to that is, of course, that people don't <i>always</i>
+do that in C, so why should they have to do it in Perl? And if there
+were no other way to do multiline comments in Perl, they'd have a
+stronger case. But there already is another way, albeit one rejected by
+this RFC as &quot;a workaround.&quot;</p>
+<p>But it seems to me that, rather than adding another kind of comment or
+trying to make something that looks like code behave like a comment,
+the solution is simply to fix whatever is wrong with POD so that its
+use for commenting can no longer be considered a workaround. Actual
+design of POD can be put off till Apocalypse 26, but we can speculate
+at this point that the rules for switching back and forth between POD
+and Perl are suboptimal for use in comments. If so, then it's likely
+that in Perl 6 we'll have a rule like this: If a <code>=begin MUMBLE</code>
+transitions from Perl to POD mode then the corresponding <code>=end MUMBLE</code>
+should transition back (without a <code>=cut</code> directive).</p>
+<p>Note that we haven't defined our <code>MUMBLE</code>s yet, but they can be set up
+to let our program have any sort of programmatic access to the data
+that we desire. For instance, it is likely that comments of this kind
+could be tied in with some sort of literate (or at least, semiliterate)
+programming framework.</p>
+<a name='RFC 102: Inline Comments for Perl'></a><h2>RFC 102: Inline Comments for Perl</h2>
+<p>I have never much liked inline comments -- as commonly practiced they
+tend to obfuscate the code as much as they clarify it. That being said,
+&quot;All is fair if you predeclare.&quot; So there should be nothing
+preventing someone from writing a lexer regex that handles them,
+provided we make the lexer sufficiently mutable. Which we will. (As it
+happens, the character sequence &quot;<code>/*</code>&quot; will be unlikely to occur in
+standard Perl 6. Which I guess means it <i>is</i> likely to occur in
+nonstandard Perl 6. <code>:-)</code></p>
+<p>A pragma declaring nonstandard commenting would also allow people to
+use <code>/* */</code> for multiline comments, if they like. (But I still think
+it'd be better to use POD directives for that, just to keep the text
+accessible to the program.)</p>
+<p>[Update: It eventually became apparent (after five years!) that we
+could simplify the distinction between postfix and infix operators
+if we had a general way to embed comments, so we now have a general
+quote-like mechanism for embedded comments such that you can say
+<code>$foo\#(bar).baz</code> to mean <code>$foo.baz</code>. Basically, if the <code>#</code>
+character is immediately followed by a bracket, that bracket pair
+determines the scope of the comment. (If you're wondering how the
+backslash/dot become one dot in the example, see the explanation of the
+&quot;long dot&quot; in S02.)]</p>
+<a name='Built-In Data Types'></a><h1>Built-In Data Types</h1>
+<p>The basic change here is that, rather than just supporting scalars,
+arrays and hashes, Perl 6 supports opaque objects as a fourth
+fundamental data type. (You might think of them as pseudo-hashes done
+right.) While a class can access its object attributes any way it
+likes, all external access to opaque objects occurs through methods,
+even for attributes. (This guarantees that attribute inheritance works
+<p>While Perl 6 still defaults to typeless scalars, Perl will be able to
+give you more performance and safety as you give it more type
+information to work with. The basic assumption is that homogenous data
+structures will be in arrays and hashes, so you can declare the type of
+the scalars held in an array or hash. Heterogenous structures can still
+be put into typeless arrays and hashes, but in general Perl 6 will
+encourage you to use classes for such data, much as C encourages you to
+use structs rather than arrays for such data.</p>
+<p>One thing we'll be mentioning before we discuss it in detail is the
+notion of &quot;properties.&quot; (In Perl 5, we called these &quot;attributes,&quot;
+but we're reserving that term for actual object attributes these days,
+so we'll call these things &quot;properties.&quot;) Variables and values can
+have additional data associated with them that is &quot;out of band&quot; with
+respect to the ordinary typology of the variable or value. For now,
+just think of properties as a way of adding ad hoc attributes to a
+class that doesn't support them. You could also think of it as a form
+of class derivation at the granularity of the individual object,
+without having to declare a complete new class.</p>
+<p>[Update: We're now calling compile-time properties &quot;traits&quot;. And objects
+don't really have properties separate from their attributes--this is now
+handled with a mixin mechanism.]</p>
+<a name='RFC 161: Everything in Perl Becomes an Object.'></a><h2>RFC 161: Everything in Perl Becomes an Object.</h2>
+<p>This is essentially a philosophical RFC that is rather short on detail.
+Nonetheless, I agree with the premise that all Perl objects should act
+like objects if you choose to treat them that way. If you choose not to
+treat them as objects, then Perl will try to go along with that, too.
+(You may use hash subscripting and slicing syntax to call attribute
+accessors, for instance, even if the attributes themselves are not
+stored in a hash.) Just because Perl 6 is more object-oriented
+internally, does not mean you'll be forced to think in object-oriented
+terms when you don't want to. (By and large, there will be a few places
+where OO-think is more required in Perl 6 than in Perl 5. Filehandles
+are more object-oriented in Perl 6, for instance, and the special
+variables that used to be magically associated with the currently
+selected output handle are better specified by association with a
+specific filehandle.)</p>
+<a name='RFC 038: Standardise Handling Of Abnormal Numbers Like Infinities and NaNs'></a><h2>RFC 038: Standardise Handling Of Abnormal Numbers Like
+Infinities and NaNs</h2>
+<p>This is likely to slow down numeric processing in some locations.
+Perhaps it could be turned off when desirable. We need to be careful
+not to invent something that is guaranteed to run slower than IEEE
+floating point. We should also try to avoid defining a type system that
+makes translation of numeric types to Java or C# types problematic.</p>
+<p>That being said, standard semantics are a good thing, and should be the
+default behavior.</p>
+<a name='RFC 043: Integrate BigInts (and BigRats) Support Tightly With the Basic Scalars'></a><h2>RFC 043: Integrate BigInts (and BigRats) Support Tightly With
+the Basic Scalars</h2>
+<p>This RFC suggests that a pragma enables the feature, but I think it
+should probably be tied to the run-time type system, which means it's
+driven more by how the data is created than by where it happens to be
+stored or processed. I don't see how we can make it a pragma, except
+perhaps to influence the meaning of &quot;int&quot; and &quot;num&quot; in actual
+declarations further on in the lexical scope:</p>
+<pre> use bigint;
+ my int $i;</pre>
+<p>might really mean</p>
+<pre> my bigint $i;</pre>
+<p>or maybe just</p>
+<pre> my int $i is bigint;</pre>
+<p>since representation specifications might just be considered part of
+the &quot;fine print.&quot; But the whole subject of lexically scoped variable
+properties specifying the nature of the objects they contain is a bit
+problematic. A variable is a sort of mini-interface, a contract if you
+will, between the program and the object in question. Properties that
+merely influence how the program sees the object are not a problem --
+when you declare a variable to be constant, you're promising not to
+modify the object through that variable, rather than saying something
+intrinsically true about the object. (Not that there aren't objects
+that are intrinsically constant.)</p>
+<p>Other property declarations might need to have some say in how
+constructors are called in order to guarantee consistency between the
+variable's view of the object, and the nature of the object itself. In
+the worst case we could try to enforce consistency at run time, but
+that's apt to be slow. If every assignment of a <code>Dog</code> object to a
+<code>Mammal</code> variable has to check to see whether <code>Dog</code> is a <code>Mammal</code>,
+then the assignment is going to be a dog.</p>
+<p>So we'll have to revisit this when we're defining the relationship
+between variable declarations and constructors. In any event, if we
+don't make Perl's numeric types automatically promote to big
+representations, we should at least make it easy to specify it when you
+<i>want</i> that to happen.</p>
+<p>[Update: The <code>Int</code> type automatically upgrades to arbitrary precision
+internally. The <code>int</code> type does not.]</p>
+<a name='RFC 192: Undef Values ne Value'></a><h2>RFC 192: Undef Values ne Value</h2>
+<p>I've rejected this one, because I think something that's undefined
+should be considered just that, undefined. I think the standard
+semantics are useful for catching many kinds of errors.</p>
+<p>That being said, it'll hopefully be easy to modify the standard
+operators within a particular scope, so I don't think we need to think
+that our way to think is the only way to think, I think.</p>
+<a name='RFC 212: Make length(@array) Work'></a><h2>RFC 212: Make <code>length(@array)</code> Work</h2>
+<p>Here's an oddity, an RFC that the author retracted, but that I accept,
+more or less. I think <code>length(@array)</code> should be equivalent to
+<code>@array.length()</code>, so if there's a <code>length</code> method available, it
+should be called.</p>
+<p>The question is whether there should be a <code>length</code> method at all, for
+strings or arrays. It almost makes more sense for arrays than it does
+for strings these days, because when you talk about the length of a
+string, you need to know whether you're talking about byte length or
+character length. So we may split up the traditional length function
+into two, in which case we might end up with:</p>
+<pre> $foo.chars
+ $foo.bytes
+ @foo.elems</pre>
+<p>Or some such. Whatever the method names we choose, differentiating them
+would be more powerful in supplying context. For instance, one could
+envision calling <code>@foo.bytes</code> to return the byte length of all the
+strings. That wouldn't fly if we overloaded the method name.</p>
+<p>Even <code>chars($foo)</code> might not be sufficiently precise, since, depending
+on how you're processing Unicode, you might want to know how long the
+string is in actual characters, not counting combining characters that
+don't take extra space. But that's a topic for later.</p>
+<p>[Update: There is no <code>length</code> function. There are <code>bytes</code>,
+<code>codes</code>, <code>graphs</code>, and <code>langs</code> methods for the various Unicode
+support levels. (The <code>chars</code> method returns one of those values
+depending on the current Unicode support level.) Arrays and hashes
+report number of elements with the <code>elems</code> method.]</p>
+<a name='RFC 218: my Dog $spot Is Just an Assertion'></a><h2>RFC 218: <code>my Dog $spot</code> Is Just an Assertion</h2>
+<p>I expect that a declaration of the form:</p>
+<pre> my Dog $spot;</pre>
+<p>is merely an assertion that you will not use <code>$spot</code> inconsistently
+with it being a <code>Dog</code>. (But I mean something different by
+&quot;assertion&quot; than this RFC does.) This assertion may or may not be
+tested at every assignment to <code>$spot</code>, depending on pragmatic context.
+This bare declaration does not call a constructor; however, there may
+be forms of declaration that do. This may be necessary so that the
+variable and the object can pass properties back and forth, and in
+general, make sure they're consistent with each other. For example, you
+might declare an array with a multidimensional shape, and this shape
+property needs to be visible to the constructor, if we don't want to
+have to specify it redundantly.</p>
+<p>On the other hand, we might be able to get assignment sufficiently
+overloaded to accomplish the same goal, so I'm deferring judgment on
+that. All I'm deciding here is that a bare declaration without
+arguments as above does not invoke a constructor, but merely tells the
+compiler something.</p>
+<p>[Update: The constructor may be called using the <code>.=new()</code> construct.]</p>
+<a name='Other Decisions About Types'></a><h2>Other Decisions About Types</h2>
+<p>Built-in object types will be in all uppercase: <code>INTEGER</code>, <code>NUMBER</code>,
+<code>STRING</code>, <code>REF</code>, <code>SCALAR</code>, <code>ARRAY</code>, <code>HASH</code>, <code>REGEX</code> and <code>CODE</code>.
+Corresponding to at least some of these, there will also be lowercase
+intrinsic types, such as <code>int</code>, <code>num</code>, <code>str</code> and <code>ref</code>. Use of the
+lowercase typename implies you aren't intending to do anything fancy
+OO-wise with the values, or store any run-time properties, and thus
+Perl should feel free to store them compactly. (As a limiting case,
+objects of type <code>bit</code> can be stored in one bit.) This distinction
+corresponds roughly to the boxed/unboxed distinction of other computer
+languages, but it is likely that Perl 6 will attempt to erase the
+distinction for you to the extent possible. So, for instance, an <code>int</code>
+may still be used in a string context, and Perl will convert it for
+you, but it won't cache it, so the next time you use it as a string, it
+will have to convert again.</p>
+<p>[Update: The object types are no longer all caps, but <code>Int</code>, <code>Num</code>,
+<code>Str</code>, etc.]</p>
+<p>The declared type of an array or hash specifies the type of each
+element, not the type of an array or hash as a whole. This is justified
+by the notion that an array or hash is really just a strange kind of
+function that (typically) takes a subscript as an argument and returns
+a value of a particular type. If you wish to associate a type with the
+array or hash as a whole, that involves setting a <code>tie</code> property. If
+you find yourself wishing to declare different types on different
+elements, it probably means that you should either be using a class for
+the whole heterogenous thing, or at least declare the type of array or
+hash that will be a base class of all the objects it will contain.</p>
+<p>Of course, untyped arrays and hashes will be just as acceptable as they
+are currently. But a language can only run so fast when you force it to
+defer all type checking and method lookup till run time.</p>
+<p>The intent is to make use of type information where it's useful, and
+not require it where it's not. Besides performance and safety, one
+other place where type information is useful is in writing interfaces
+to other languages. It is postulated that Perl 6 will provide enough
+optional type declaration syntax that it will be unnecessary to write
+XS-style glue in most cases.</p>
+<p>[Update: Turns out one of the most important reasons for adding type
+information is that it allows for multimethod dispatch.]</p>
+<a name='Variables'></a><h1>Variables</h1>
+<a name='RFC 071: Legacy Perl $pkg'var Should Die'></a><h2>RFC 071: Legacy Perl $pkg'var Should Die</h2>
+<p>I agree. I was unduly influenced by Ada syntax here, and it was a
+mistake. And although we're adding a properties feature into Perl 6
+that is much like Ada's attribute feature, we won't make the mistake of
+reintroducing a syntax that drives highlighting editors nuts. We'll try
+to make different mistakes this time.</p>
+<a name='RFC 009: Highlander Variable Types'></a><h2>RFC 009: Highlander Variable Types</h2>
+<p>I basically agree with the problem this RFC is trying to solve, but I
+disagree with the proposed solution. The basic problem is that, while
+the idiomatic association of <code>$foo[$bar]</code> with <code>@foo</code> rather than
+<code>$foo</code> worked fine in Perl 4, when we added recursive data structures
+to Perl 5, it started getting in the way notationally, so that initial
+funny character was trying to do too much in both introducing the
+&quot;root&quot; of the reference, as well as the context to apply to the final
+subscript. This necessitated odd looking constructions like:</p>
+<pre> $foo-&gt;[1][2][3]</pre>
+<p>This RFC proposes to solve the dilemma by unifying scalar variables
+with arrays and hashes at the name level. But I think people like to
+think of <code>$foo</code>, <code>@foo</code> and <code>%foo</code> as separate variables, so I don't
+want to break that. Plus, the RFC doesn't unify <code>&amp;foo</code>, while it's
+perfectly possible to have a reference to a function as well as a
+reference to the more ordinary data structures.</p>
+<p>So rather than unifying the names, I believe all we have to do is unify
+the treatment of variables with respect to references. That is, all
+variables may be thought of as references, not just scalars. And in
+that case, subscripts always dereference the reference implicit in the
+array or hash named on the left.</p>
+<p>This has two major implications, however. It means that Perl
+programmers must learn to write <code>@foo[1]</code> where they used to write
+<code>$foo[1]</code>. I think most Perl 5 people will be able to get used to
+this, since many of them found the current syntax a bit weird in the
+first place.</p>
+<p>The second implication is that slicing needs a new notation, because
+subscripts no longer have their scalar/list context controlled by the
+initial funny character. Instead, the context of the subscript will
+need to be controlled by some combination of:</p>
+<li><a name='1. Context of the entire term.'></a>1. Context of the entire term.</li>
+<li><a name='2. Appearance of known list operators in the subscript, such as comma or range.'></a>2. Appearance of known list operators in the subscript, such as
+comma or range.</li>
+<li><a name='3. Explicit syntax casting the inside of the subscript to list or scalar context.'></a>3. Explicit syntax casting the inside of the subscript to list or
+scalar context.</li>
+<li><a name='4. Explicit declaration of default behavior.'></a>4. Explicit declaration of default behavior.</li>
+<p>One thing that probably shouldn't enter into it is the run-time type of
+the array object, because context really needs to be calculated at
+compile time if at all possible.</p>
+<p>In any event, it's likely that some people will want subscripts to
+default to scalars, and other people will want them to default to
+lists. There are good arguments for either default, depending on
+whether you think more like an APL programmer or a mere mortal.</p>
+<p>[Update: Rvalue subscripts are always list context, but it's trivial to
+force scalar context with either of the <code>+</code> or <code>~</code> unary operators.
+Lvalue subscripts are scalar context unless the lvalue is in parentheses.]</p>
+<p>There are other larger implications. If composite variables are thought
+of as scalar references, then the names <code>@foo</code> and <code>%foo</code> are really
+scalar variables unless explicitly dereferenced. That means that when
+you mention them in a scalar context, you get the equivalent of Perl
+5's <code>\@foo</code> and <code>\%foo</code>. This simplifies the prototyping system
+greatly, in that an operator like <code>push</code> no longer needs to specify
+some kind of special reference context for its first argument -- it can
+merely specify a scalar context, and that's good enough to assume the
+reference generation on its first argument. (Of course, the function
+signature can always be more specific if it wants to. More about that
+in future installments.)</p>
+<p>There are also implications for the assignment operator, in that it has
+to be possible to assign array references to array variables without
+accidentally invoking list context and copying the list instead of the
+reference to the list. We could invent another assignment operator to
+distinguish the two cases, but at the moment it looks as though bare
+variables and slices will behave as lvalues just as they do in Perl 5,
+while lists in parentheses will change to a binding of the right-hand
+arguments more closely resembling the way Perl 6 will bind formal
+arguments to actual arguments for function calls. That is to say,</p>
+<pre> @foo = (1,2,3);</pre>
+<p>will supply an unbounded list context to the right side, but</p>
+<pre> (@foo, @bar) = (@bar, @foo)</pre>
+<p>will supply a context to the right side that requests two scalar values
+that are array references. This will be the default for unmarked
+variables in an lvalue list, but there will be an easy way to mark
+formal array and hash parameters to slurp the rest of the arguments
+with list context, as they do by default in Perl 5.</p>
+<p>(Alternately, we might end up leaving the ordinary list assignment
+operator with Perl 5 semantics, and define a new assignment operator
+such as <code>:=</code> that does signatured assignment. I can argue that one
+both ways.)</p>
+<p>[Update: We ended up with a <code>:=</code> binding operator.]</p>
+<p>Just as arrays and hashes are explicitly dereferenced via subscripting
+(or implicitly dereferenced in list context), so too functions are
+merely named but not called by <code>&amp;foo</code>, and explicitly dereferenced
+with parentheses (or by use as a bare name without the ampersand (or
+both)). The Perl 5 meanings of the ampersand are no longer in effect,
+in that ampersand will no longer imply that signature matching is
+suppressed -- there will be a different mechanism for that. And since
+<code>&amp;foo</code> without parens doesn't do a call, it is no longer possible to
+use that syntax to automatically pass the <code>@_</code> array -- you'll have to
+do that explicitly now with <code>foo(@_)</code>.</p>
+<p>Scalar variables are special, in that they may hold either references
+or actual &quot;native&quot; values, and there is no special dereference syntax
+as there is for other types. Perl 6 will attempt to hide the
+distinction as much as possible. That is, if <code>$foo</code> contains a native
+integer, calling the <code>$</code> method will call a method on the
+built-in type. But if <code>$foo</code> contains a reference to some other
+object, it will call the method on that object. This is consistent with
+the way we think about overloading in Perl 5, so you shouldn't find
+this behavior surprising. It may take special syntax to get at any
+methods of the reference variable itself in this case, but it's OK if
+special cases are special.</p>
+<p>[Update: The <code>variable($foo)</code> pseudo-function allows you to specify the
+container rather than the contained object.]</p>
+<a name='RFC 133: Alternate Syntax for Variable Names'></a><h2>RFC 133: Alternate Syntax for Variable Names</h2>
+<p>This RFC has a valid point, but in fact we're going to do just the
+opposite of what it suggests. That is, we'll consider the funny
+characters to be part of the name, and use the subscripts for context.
+This works out better, because there's only one funny character, but
+many possible forms of dereferencing.</p>
+<p>[Update: Nowadays we call those funny characters <i>sigils</i>. And for weirdly
+scoped variables there's a second character called a <i>twigil</i>.]</p>
+<a name='RFC 134: Alternative Array and Hash Slicing'></a><h2>RFC 134: Alternative Array and Hash Slicing</h2>
+<p>We're definitely killing Perl 5's slice syntax, at least as far as
+relying on the initial character to determine the context of the
+subscript. There are many ways we could reintroduce a slicing syntax,
+some of which are mentioned in this RFC, but we'll defer the decision
+on that till Apocalypse 9 on Data Structures, since the interesting
+parts of designing slice syntax will be driven by the need to slice
+multidimensional arrays.</p>
+<p>[Update: There is no Apocalypse 9, but there is a Synopsis 9 that
+covers these matters.]</p>
+<p>For now we'll just say that arrays can have subscript signatures much
+like functions have parameter signatures. Ordinary one-dimensional
+arrays (and hashes) can then support some kind of simple slicing syntax
+that can be extended for more complicated arrays, while allowing
+multidimensional arrays to distinguish between simple slicing and
+complicated mappings of lists and functions onto subscripts in a manner
+more conducive to numerical programming.</p>
+<p>On the subject of hash slices returning pairs rather than values, we
+could distinguish this with special slice syntax, or we could establish
+the notion of a hashlist context that tells the slice to return pairs
+rather than just values. (We may not need a special slice syntax for
+that if it's possible to typecast back and forth between pair lists and
+ordinary lists.)</p>
+<p>[Update: Slicing to get a pairlist can be done by attaching a <code>:p</code>
+modifier to the subscript. In general though there's no such thing
+as a hashlist context. It's just that the list context supplied by
+assignment to a hash happens to know how to deal with pairs.]</p>
+<a name='RFC 196: More Direct Syntax for Hashes'></a><h2>RFC 196: More Direct Syntax for Hashes</h2>
+<p>This RFC makes three proposals, which we'll consider separately.</p>
+<p>Proposal 1 is &quot;that a hash in scalar context evaluate to the number of
+keys in the hash.&quot; (You can find that out now, but only by using the
+<code>keys()</code> function in scalar context.) Proposal 1 is OK if we change
+&quot;scalar context&quot; to &quot;numeric context,&quot; since in scalar context a
+hash will produce a reference to the hash, which just happens to numify
+to the number of entries.</p>
+<p>We must also realize that some implementations of hash might have to go
+through and count all the entries to return the actual number.
+Fortunately, in boolean context, it suffices to find a single entry to
+determine whether the hash contains anything. However, on hashes that
+don't keep track of the number of entries, finding even one entry might
+reset any active iterator on the hash, since some implementations of
+hash (in particular, the ones that don't keep track of the number of
+entries) may only supply a single iterator.</p>
+<p>[Update: You may also call <code>.elems</code> to be more explicit.]</p>
+<p>Proposal 2 is &quot;that the iterator in a hash be reset through an
+explicit call to the <code>reset()</code> function.&quot; That's fine, with the
+proviso that it won't be a function, but rather a <i>method</i> on the HASH
+<p>[Update: all list contexts in Perl 6 are lazy by default, and different
+list contexts generate their own iterators, so all you have to do to
+&quot;reset&quot; and iterator is stop reading from the list in question.]</p>
+<p>Proposal 3 is really about <code>sort</code> recognizing pairs and doing the
+right thing. Defaulting to sorting on <code>$^a[0] cmp $^b[0]</code> is likely to
+be reasonable, and that's where a pair's key would be found. However,
+it's probable that the correct solution is simply to provide a default
+string method for anonymous lists that happens to produce a decent key
+to sort on when <code>cmp</code> requests a string representation of either of
+its arguments. The <code>sort</code> itself should probably just concentrate on
+memoizing the returned strings so they don't have to be recalculated.</p>
+<p>[Update: The <code>sort</code> interface has been completely revamped since this
+was written. This will eventually appear in S29, but as of now it's
+just in the perl6-language archives.]</p>
+<a name='RFC 201: Hash Slicing'></a><h2>RFC 201: Hash Slicing</h2>
+<p>This RFC proposes to use <code>%</code> as a marker for special hash slicing in
+the subscript. Unfortunately, the <code>%</code> funny character will not be
+available for this use, since all hash refs will start with <code>%</code>.
+Concise list comprehensions will require some other syntax within the
+subscript, which will hopefully generalize to arrays as well.</p>
+<a name='Other Decisions About Variables'></a><h2>Other Decisions About Variables</h2>
+<p>Various special punctuation variables are gone in Perl 6, including all
+the deprecated ones. (Non-deprecated variables will be replaced by some
+kind of similar functionality that is likely to be invoked through some
+kind of method call on the appropriate object. If there is no
+appropriate object, then a named global variable might provide similar
+<p>Freeing up the various bracketing characters allows us to use them for
+other purposes, such as interpolation of expressions:</p>
+<pre> &quot;$(expr)&quot; # interpolate a scalar expression
+ &quot;@(expr)&quot; # interpolate a list expression</pre>
+<p>[Update: Those forms mean something else now (casting). Expression
+interpolation is normally done via closure.]</p>
+<p><code>$#foo</code> is gone. If you want the final subscript of an array, and
+<code>[-1]</code> isn't good enough, use <code>@foo.end</code> instead.</p>
+<p>Other special variables (such as the regex variables) will change from
+dynamic scoping to lexical scoping. It is likely that even <code>$_</code> and
+<code>@_</code> will be lexically scoped in Perl 6.</p>
+<p>[Update: And indeed they are. But they happen to be a special kind of
+lexical variable called an &quot;environment&quot; variable, modeled on Unix
+environment variables. This allows subroutines to get at them and use
+them as defaults, in a pronominal sort of way.]</p>
+<a name='Names'></a><h1>Names</h1>
+<p>In Perl 5, lexical scopes are unnamed and unnameable. In Perl 6, the
+current lexical scope will have a name that is visible within the
+lexical scope as the pseudo class <code>MY</code>, so that such a scope can, if
+it so chooses, delegate management of its lexical scope to some other
+module at compile time. In normal terms, that means that when you use a
+module, you can let it import things lexically as well as packagely.</p>
+<p>[Update: The currently compiling lexical scope may also be named from anywhere
+as the <code>COMPILING</code> pseudopackage these days.]</p>
+<p>Typeglobs are gone. Instead, you can get at a variable object through
+the symbol table hashes that are structured much like Perl 5's. The
+variable object for <code>$MyPackage::foo</code> is stored in:</p>
+<pre> %MyPackage::{'$foo'}</pre>
+<p>Note that the funny character is part of the name. There is no longer
+any structure in Perl that associates everything with the name
+<p>[Update: The right way to say that now is &quot;<code>MyPackage::&lt;$foo&gt;</code>&quot;.
+Hence the <code>$foo</code> variable in the scope currently being compiled is
+known as <code>COMPILING::&lt;$foo&gt;</code>.]</p>
+<p>Perl's special global names are stored in a special package named
+&quot;<code>*</code>&quot; because they're logically in every scope that does not hide
+them. So the unambiguous name of the standard input filehandle is
+<code>$*STDIN</code>, but a package may just refer to <code>$STDIN</code>, and it will
+default to <code>$*STDIN</code> if no package or lexical variable of that name
+has been declared.</p>
+<p>[Update: We did s/STD// on those, so standard input is now just <code>$*IN</code>.]</p>
+<p>Some of these special variables may actually be cloned for each lexical
+scope or each thread, so just because a name is in the special global
+symbol table doesn't mean it always behaves as a global across all
+modules. In particular, changes to the symbol table that affect how the
+parser works must be lexically scoped. Just because I install a special
+rule for my cool new hyperquoting construct doesn't mean everyone else
+should have to put up with it. In the limiting case, just because I
+install a Python parser, it shouldn't force other modules into a maze
+of twisty little whitespace, all alike.</p>
+<p>Another way to look at it is that all names in the &quot;<code>*</code>&quot; package are
+automatically exported to every package and/or outer lexical scope.</p>
+<p>[Update: The names are no longer automatically exported, but you can import
+them from the global namespace via &quot;<code>use GLOBALS '$IN', '$OUT';</code>&quot; and such.]</p>
+<a name='Literals'></a><h1>Literals</h1>
+<a name='Underscores in Numeric Literals'></a><h2>Underscores in Numeric Literals</h2>
+<p>Underscores will be allowed between any two digits within a number.</p>
+<a name='RFC 105: Remove &quot;In string @ must be \@&quot; Fatal Error'></a><h2>RFC 105: Remove &quot;In string @ must be \@&quot; Fatal Error</h2>
+<p>[Update: The interpolation rules for arrays have been completely revised.
+A bare array name no longer interpolates--you have to say <code>@foo[]</code>.]</p>
+<a name='RFC 111: Here Docs Terminators (Was Whitespace and Here Docs)'></a><h2>RFC 111: Here Docs Terminators (Was Whitespace and Here Docs)</h2>
+<a name='RFC 162: Heredoc contents'></a><h2>RFC 162: Heredoc contents</h2>
+<p>I think I like option (e) the best: remove whitespace equivalent to the
+<p>By default, if it has to dwim, it should dwim assuming that hard tabs
+are 8 spaces wide. This should not generally pose a problem, since most
+of the time the tabbing will be consistent throughout anyway, and no
+dwimming will be necessary. This puts the onus on people using
+nonstandard tabs to make sure they're consistent so that Perl doesn't
+have to guess.</p>
+<p>Any additional mangling can easily be accomplished by a user-defined
+<p>[Update: Here docs are now just a :to variant on extensible quotes, so
+any customization you can do to <code>q/foo/</code> you can also do to <code>q:to/END/</code>.</p>
+<a name='RFC 139: Allow Calling Any Function With a Syntax Like s///'></a><h2>RFC 139: Allow Calling Any Function With a Syntax Like s///</h2>
+<p>Creative quoting will be allowed with lexical mutataion, but we can't
+parse <code>foo(bar)</code> two different ways simultaneously, and I'm unwilling
+to prevent people from using parens as quote characters. I don't see
+how we can reasonably have new quote operators without explicit
+declaration. And if the utility of a quote-like operator is sufficient,
+there should be little relative burden in requiring such a declaration.</p>
+<p>The form of such a declaration is left to the reader as an exercise in
+function property definition. We may revisit the question later in this
+series. It's also possible that a quote operator such as <code>qx//</code> could
+have a corresponding function name like <code>quote:qx</code> that could be
+invoked as a function.</p>
+<a name='RFC 222: Interpolation of Object Method Calls'></a><h2>RFC 222: Interpolation of Object Method Calls</h2>
+<p>I've been hankering for methods to interpolate for a long time, so I'm
+in favor of this RFC. And it'll become doubly important as we move
+toward encouraging people to use accessor methods to refer to object
+attributes outside the class itself.</p>
+<p>I have one &quot;but,&quot; however. Since we'll switch to using <code>.</code> instead
+of <code>-&gt;</code>, I think for sanity's sake we may have to require the
+parentheses, or &quot;<code>$file.$ext</code>&quot; is going to give people fits. Not to
+mention &quot;<code>$file.ext</code>&quot;.</p>
+<p>[Update: Nowadays we also require brackets on array interpolations
+and braces on hash interpolations. See S03 for more.]</p>
+<a name='RFC 226: Selective Interpolation in Single Quotish Context.'></a><h2>RFC 226: Selective Interpolation in Single Quotish Context.</h2>
+<p>This proposal has much going for it, but there are also difficulties,
+and I've come close to rejecting it outright simply because the
+single-quoting policy of Perl 5 has been successful. And I think the
+proposal in this RFC for <code>\I</code>...<code>\E</code> is ugly. (And I'd like to kill
+<code>\E</code> anyway, and use bracketed scopings.)</p>
+<p>However, I think there is a major &quot;can't get there from here&quot; that we
+could solve by treating interpolation into single quotes as something
+hard, not something easy. The basic problem is that it's too easy to
+run into a <code>\$</code> or <code>\@</code> (or a <code>\I</code> for that matter) that wants to be
+taken literally. I think we could allow the interpolation of arbitrary
+expressions into single-quoted strings, but only if we limit it to an
+unlikely sequence where three or more characters are necessary for
+recognition. The most efficient mental model would seem to be the idea
+of embedding one kind of quote in another, so I think this:</p>
+<pre> \q{stuff}</pre>
+<p>will embed single-quoted stuff, while this:</p>
+<pre> \qq{stuff}</pre>
+<p>will embed double-quoted stuff. A variable could then be interpolated
+into a single-quoted string by saying:</p>
+<pre> \qq{$foo}</pre>
+<a name='RFC 237: Hashes Should Interpolate in Double-Quoted Strings'></a><h2>RFC 237: Hashes Should Interpolate in Double-Quoted Strings</h2>
+<p>I agree with this RFC in principle, but we can't define the default
+hash stringifier in terms of variables that are going away in Perl 6,
+so the RFC's proposal of using <code>$&quot;</code> is right out.</p>
+<p>All objects should have a method by which they produce readable output.
+How this may be overridden by user preference is open to debate.
+Certainly, dynamic scoping has its problems. But lexical override of an
+object's preferences is also problematic. Individual object properties
+appear to give a decent way out of this. More on that below.</p>
+<p>[Update: Hash values by default interpolate with tabs between key
+and value, and with newline between pairs. But you can give it a specific
+format with the <code>.as</code> method.]</p>
+<p>On <code>printf</code> formats, I don't see any way to dwim that <code>%d</code> isn't an
+array, so we'll just have to put formats into single quotes in general.
+Those format strings that also interpolate variables will be able to
+use the new <code>\qq{$var}</code> feature.</p>
+<p>[Update: Since hash interpolations require braces now, <code>printf</code> formats
+are safe again (unless they happen to be followed by curlies).]</p>
+<p>Note for those who are thinking we should just stick with Perl 5
+interpolation rules: We have to allow <code>%</code> to introduce interpolation
+now because individual hash values are no longer named with
+<code>$foo{$bar}</code>, but rather <code>%foo{$bar}</code>. So we might as well allow
+interpolation of complete hashes.</p>
+<a name='RFC 251: Interpolation of Class Method Calls'></a><h2>RFC 251: Interpolation of Class Method Calls</h2>
+<p>Class method calls are relatively rare (except for constructors, which
+will be rarely interpolated). So rather than scanning for identifiers
+that might introduce a class, I think we should just depend on
+expression interpolation instead:</p>
+<pre> &quot;There are $(Dog.numdogs) dogs.&quot;</pre>
+<p>[Update: That's now done with closure interpolation.]</p>
+<a name='RFC 252: Interpolation of Subroutines'></a><h2>RFC 252: Interpolation of Subroutines</h2>
+<p>I think subroutines should interpolate, provided they're introduced
+with the funny character. (On the other hand, how hard is
+<code>$(sunset $date)</code> or <code>@(sunset $date)</code>? On the gripping hand, I
+like the consistency of <code>&amp;</code> with <code>$</code>, <code>@</code> and <code>%</code>.)</p>
+<p>I think the parens are required, since in Perl 6, scalar <code>&amp;sub</code> will
+just return a reference, and require parens if you really want to deref
+the sub ref. (It's true that a subroutine can be called without parens
+when used as a list operator, but you can't interpolate those without a
+funny character.)</p>
+<p>For those worried about the use of <code>&amp;</code> for signature checking
+suppression, we should point out that <code>&amp;</code> will no longer be the way to
+suppress signature checking in Perl 6, so it doesn't matter.</p>
+<a name='RFC 327: \v for Vertical Tab'></a><h2>RFC 327: <code>\v</code> for Vertical Tab</h2>
+<p>I think the opportunity cost of not reserving <code>\v</code> for future use is
+too high to justify the small utility of retaining compatibility with a
+feature virtually nobody uses anymore. For instance, I almost used
+<code>\v</code> and <code>\V</code> for switching into and out of verbatim (single-quote)
+mode, until I decided to unify that with quoting syntax and use
+<code>\qq{}</code> and <code>\q{}</code> instead.</p>
+<p>[Update: Turns out that <code>\v</code> matches vertical whitespace in patterns,
+which conveniently includes vertical tab--whatever that is... Also we
+now have <code>\h</code> for horizontal whitespace.]</p>
+<a name='RFC 328: Single quotes don't interpolate \' and \\'></a><h2>RFC 328: Single quotes don't interpolate \' and \\</h2>
+<p>I think hyperquotes will be possible with a declaration of your quoting
+rules, so we're not going to change the basic single-quote rules
+(except for supporting <code>\q</code>).</p>
+<p>[Update: There are adverbial modifiers now that can do hyperquoting. See S02.]</p>
+<a name='Other Decisions About Literals'></a><h2>Other Decisions About Literals</h2>
+<a name='Scoping of \L et al.'></a><h3>Scoping of \L et al.</h3>
+<p>I'd like to get rid of the gratuitously ugly <code>\E</code> as an end-of-scope
+marker. Instead, if any sequence such as <code>\L</code>, <code>\U</code> or <code>\Q</code> wishes
+to impose a scope, then it must use curlies around that scope:
+<code>\L{<i>stuff</i>}</code>, <code>\U{<i>stuff</i>}</code> or <code>\Q{<i>stuff</i>}</code>. Any literal
+curlies contained in <i>stuff</i> must be backslashed. (Curlies as syntax
+(such as for subscripts) should nest correctly.)</p>
+<p>[Update: Those constructs are now gone entirely. Use closure interpolation
+to interpolate the value of an expression.]</p>
+<a name='Bareword Policy'></a><h3>Bareword Policy</h3>
+<p>There will be no barewords in Perl 6. Any bare name that is a declared
+package name will be interpreted as a class object that happens to
+stringify to the package name. All other bare names will be interpreted
+as subroutine or method calls. For nonstrict applications, undefined
+subroutines will autodefine themselves to return their own name. Note
+that in <code>${name}</code> and friends, the name is considered autoquoted, not
+a bareword.</p>
+<p>[Update: The <code>${name}</code> construct is gone. Use closure interpolation
+to disambiguate expression interpolations: <code>&quot;{$name}text&quot;</code>.
+Use <code>$($ref)</code> or <code>$$ref</code> for hard dereferences.
+Use <code>$::($name)</code> for symbolic dereferences.]</p>
+<a name='Weird brackets'></a><h3>Weird brackets</h3>
+<p>Use of brackets to disambiguate</p>
+<pre> &quot;${foo[bar]}&quot;</pre>
+<pre> &quot;${foo}[bar]&quot;</pre>
+<p>will no longer be supported. Instead, the expression parser will always
+grab as much as it can, and you can make it quit at a particular point
+by interpolating a null string, specified by <code>\Q</code>:</p>
+<pre> &quot;$foo\Q[bar]&quot;</pre>
+<p>[Update: That's gone too. Just use closure interpolation to disambiguate.]</p>
+<a name='Special tokens'></a><h3>Special tokens</h3>
+<p>Special tokens will turn into either POD directives or lexically scoped
+OO methods under the <code>MY</code> pseudo-package:</p>
+<pre> Old New
+ --- ---
+ __LINE__ MY.line
+ __FILE__ MY.file
+ __PACKAGE__ MY.package
+ __END__ =begin END (or remove)
+ __DATA__ =begin DATA</pre>
+<p>[Update: The first three are now <code>$?LINE</code>, <code>$?FILE</code>, and <code>$?PACKAGE</code>.
+There are other such variables too. See S02.]</p>
+<a name='Heredoc Syntax'></a><h3>Heredoc Syntax</h3>
+<p>I think heredocs will require quotes around any identifier, and we need
+to be sure to support <code>&lt;&lt; qq(END)</code> style quotes. Space is
+now allowed before the (required) quoted token. Note that custom
+quoting is now possible, so if you define a fancy <code>qh</code> operator for
+your fancy hyperquoting algorithm, then you could say <code>&lt;&lt;qh(END)</code>.</p>
+<p>It is still the case that you can say <code>&lt;&lt;&quot;&quot;</code> to grab
+everything up to the next blank line. However, Perl 6 will consider any
+line containing only spaces, tabs, etc., to be blank, not just the ones
+that immediately terminate with newline.</p>
+<p>[Update: <code>q:to/END/</code> is now how you form a here doc.]</p>
+<a name='Context'></a><h1>Context</h1>
+<p>In Perl 5, a lot of contextual processing was done at run-time, and
+even then, a given function could only discover whether it was in void,
+scalar or list context. In Perl 6, we will extend the notion of context
+to be more amenable to both compile-time and run-time analysis. In
+particular, a function or method can know (theoretically even at
+compile time) when it is being called in:</p>
+<pre> Void context
+ Scalar context
+ Boolean context
+ Integer context
+ Numeric context
+ String context
+ Object context
+ List context
+ Flattening list context (true list context).
+ Non-flattening list context (list of scalars/objects)
+ Lazy list context (list of closures)
+ Hash list context (list of pairs)</pre>
+<p>(This list isn't necessarily exhaustive.)</p>
+<p>Each of these contexts (except maybe void) corresponds to a way in
+which you might declare the parameters of a function (or the left side
+of a list assignment) to supply context to the actual argument list (or
+right side of a list assignment). By default, parameters will supply
+object context, meaning individual parameters expect to be aliases to
+the actual parameters, and even arrays and hashes don't do list context
+unless you explicitly declare them to. These aren't cast in stone yet
+(or even Jello), but here are some ideas for possible parameter
+declarations corresponding to those contexts:</p>
+<pre> Scalar context
+ Boolean context bit $arg
+ Integer context int $arg
+ Numeric context num $arg
+ String context str $arg
+ Object context $scalar, %hash, Dog @canines, &amp;foo
+ List context
+ Flattening list context *@args
+ Non-flattening list context $@args
+ Lazy list context &amp;@args
+ Hash list context *%args</pre>
+<p>[Update: Some of these are bogus. See S06 for the most recent
+formulation. In general, most functions should not be asking for
+their context, but should return something that works in any context.]</p>
+<p>(I also expect unary * to force flattening of arrays in rvalue
+contexts. This is how we defeat the type signature in Perl 6, instead
+of relying on the initial ampersand. So instead of Perl 5's
+<code>&amp;push(@list)</code>, you could just say <code>push *@list</code>, and it wouldn't
+matter what <code>push</code>'s parameter signature said.)</p>
+<p>[Update: Lazy flattening is now done with the <code>[,]</code> reduce operator.
+Eager flattening is done with the <code>eager</code> list operator.]</p>
+<p>It's also possible to define properties to modify formal arguments,
+though that can get clunky pretty quickly, and I'd like to have a
+concise syntax for the common cases, such as the last parameter
+slurping a list in the customary fashion. So the signature for the
+built-in <code>push</code> could be</p>
+<pre> sub push (@array, *@pushees);</pre>
+<p>Actually, the signature might just be <code>(*@pushees)</code>, if <code>push</code> is
+really a method in the <code>ARRAY</code> class, and the object is passed
+<pre> class ARRAY;
+ sub .push (*@pushees);
+ sub .pop (;int $numtopop);
+ sub .splice (int $offset, int $len, *@repl);</pre>
+<p>But we're getting ahead of ourselves.</p>
+<p>[Update: Indeed, methods are declared with a <code>method</code> keyword, and
+without the dot. Also the built-in class is <code>Array</code>, not <code>ARRAY</code>.
+See A12 and S12 for much more about classes and methods.]</p>
+<p>By the way, all function and method parameters (other than the object
+itself) will be considered read-only unless declared with the <code>rw</code>
+property. (List assignments will default the other way.) This will
+prevent a great deal of the wasted motion current Perl implementations
+have to go through to make sure all function arguments are valid
+lvalues, when most of them are in fact never modified.</p>
+<p>Hmm, we're still getting ahead of ourselves. Back to contexts.</p>
+<a name='References are now transparent to boolean context'></a><h2>References are now transparent to boolean context</h2>
+<p>References are no longer considered to be &quot;always true&quot; in Perl 6.
+Any type can overload its <code>bit()</code> casting operator, and any type that
+hasn't got a <code>bit()</code> of its own inherits one from somewhere else, if
+only from class UNIVERSAL. The built-in bit methods have the expected
+boolean semantics for built-in types, so arrays are still true if they
+have something in them, strings are true if they aren't <code>&quot;&quot;</code> or
+<code>&quot;0&quot;</code>, etc.</p>
+<p>[Update: The universal object class is nowadays called &quot;<code>Object</code>&quot;. The
+universal type is called &quot;<code>Any</code>&quot;. And references aren't really references
+anymore. But it's still true that the individual object decides whether
+to be true or false according to its type.]</p>
+<a name='Lists'></a><h1>Lists</h1>
+<a name='RFC 175: Add list keyword to force list context (like scalar)'></a><h2>RFC 175: Add <code>list</code> keyword to force list context (like
+<p>Another RFC rescued from the compost pile. In Perl 6, type names will
+identify casting functions in general. (A casting function merely
+forces context -- it's a no-op unless the actual context is different.)
+In Perl 6, a list used in a scalar context will automatically turn
+itself into a reference to the list rather than returning the last
+element. (A subscript of <code>[-1]</code> can always be used to get the last
+element explicitly, if that's actually desired. But that's a rarity, in
+practice.) So it works out that the explicit list composer:</p>
+<pre> [1,2,3]</pre>
+<p>is syntactic sugar for something like:</p>
+<pre> scalar(list(1,2,3));</pre>
+<p>Depending on whether we continue to make a big deal of the list/array
+distinction, that might actually be spelled:</p>
+<pre> scalar(array(1,2,3));</pre>
+<p>Other casts might be words like <code>hash</code> (supplying a pairlist context)
+and <code>objlist</code> (supplying a scalar context to a list of expressions).
+Maybe even the optional <code>sub</code> keyword could be considered a cast on a
+following block that might not otherwise be considered a closure in
+context. Perhaps <code>sub</code> is really spelled <code>lazy</code>. In which case, we
+might even have a <code>lazylist</code> context to supply a lazy context to a
+list of expressions.</p>
+<p>[Update: Most of these aren't necessary. Just use the appropriate method.]</p>
+<p>And of course, you could use standard casts like <code>int()</code>, <code>num()</code>,
+and <code>str()</code>, when you want to be explicit about such contexts at
+compile time. (Perl 5 already has these contexts, but only at run
+time.) Note also that, due to the relationship between unary functions
+and methods, <code>$</code>, <code>$foo.num</code>, and <code>$foo.str</code> will be just a
+different way to write the same casts.</p>
+<p>Lest you worry that your code is going to be full of casts, I should
+point out that you won't need to use these casts terribly often because
+each of these contexts will typically be implied by the signature of
+the function or method you're calling. (And Perl will still be
+autoconverting for you whenever it makes sense.) More on that in
+Apocalypse 6, Subroutines. If not sooner.</p>
+<p>So, while boolean context might be explicitly specified by writing:</p>
+<pre> if (bit $foo)</pre>
+<pre> if ($foo.bit)</pre>
+<p>you'd usually just write it as in Perl 5:</p>
+<pre> if ($foo)</pre>
+<p>[Update: The parens are now optional, so that's just &quot;<code>if $foo</code>&quot;.]</p>
+<a name='Other Decisions about Lists'></a><h2>Other Decisions about Lists</h2>
+<p>Based on some of what we've said, you can see that we'll have the
+ability to define various kinds of lazily generated lists. The specific
+design of these operators is left for subsequent Apocalypses, however.
+I will make one observation here, that I think some of the proposals
+for how array subscripts are generated should be generalized to work
+outside of subscripts as well. This may place some constraints on the
+general use of the <code>:</code> character in places where an operator is
+expected, for instance.</p>
+<p>[Update: And indeed, we now have adverbs that look like <code>:foo(1)</code>.]</p>
+<p>As mentioned above, we'll be having several different kinds of list
+context. In particular, there will be a hash list context that assumes
+you're feeding it pairs, and if you don't feed it pairs, it will assume
+the value you feed it is a key, and supply a default value. There will
+likely be ways to get hashes to default to interesting values such as 0
+or 1.</p>
+<p>[Update: there isn't really a hash list context.]</p>
+<p>In order to do this, the <code>=&gt;</code> operator has to at least mark its
+left operand as a key. More likely, it actually constructs a pair
+object in Perl 6. And the <code>{ foo =&gt; $bar }</code> list composer will be
+required to use <code>=&gt;</code> (or be in a hashlist context), or it will
+instead be interpreted as a closure without a <code>sub</code>. (You can always
+use an explicit <code>sub</code> or <code>hash</code> to cast the brackets to the proper
+<p>I've noticed how many programs use <code>qw()</code> all over the place (much
+more frequently than the input operator, for instance), and I've always
+thought <code>qw()</code> was kind of ugly, so I'd like to replace it with
+something prettier. Since the input operator is using up a pair of
+perfectly good bracketing characters for little syntactic gain, we're
+going to steal those and make them into a qw-like list composer. In
+ordinary list context, the following would be identical:</p>
+<pre> @list = &lt; foo $bar %baz blurch($x) &gt;;
+ @list = qw/ foo $bar %baz blurch($x) /; # same as this
+ @list = ('foo', '$bar', '%baz', 'blurch($x)'); # same as this</pre>
+<p>But in hashlist context, it might be equivalent to this:</p>
+<pre> %list = &lt; foo $bar %baz blurch($x) &gt;;
+ %list = (foo =&gt; 1, '$bar' =&gt; 1, '%baz' = 1, blurch =&gt; $x); # same as this</pre>
+<p>[Update: There is also a version with French quotes <code>«»</code> that does
+interpolation before splitting into words. Either can be used as a
+hash subscript slice.]</p>
+<a name='Files'></a><h1>Files</h1>
+<p>Basically, file handles are just objects that can be used as iterators,
+and don't belong in this chapter anymore.</p>
+<a name='RFC 034: Angle Brackets Should Not Be Used for File Globbing'></a><h2>RFC 034: Angle Brackets Should Not Be Used for File Globbing</h2>
+<p>Indeed, they won't be. In fact, angle brackets won't be used for input
+at all, I suspect. See below. Er, above.</p>
+<p>[Update: Angle brackets don't directly do input. There is a unary <code>=</code>
+that does the equivalent. For an argument it takes a filehandle,
+interator, filename, or list of any of those, and returns lines.
+There is a corresponding <code>lines</code> list operator.]</p>
+<a name='RFC 051: Angle Brackets Should Accept Filenames and Lists'></a><h2>RFC 051: Angle Brackets Should Accept Filenames and Lists</h2>
+<p>There is likely to be no need for an explicit input operator in Perl 6,
+and I want the angles for something else. I/O handles are a subclass of
+iterators, and I think general iterator variables will serve the
+purpose formerly served by the input operator, particularly since they
+can be made to do the right Thing in context. For instance, to read
+from standard input, it will suffice to say</p>
+<pre> while ($STDIN) { ... }</pre>
+<p>and the iterator will know it should assign to <code>$_</code>, because it's in a
+Boolean context.</p>
+<p>[Update: No, this confuses two different meanings of boolean. Use
+<code>for =$*IN {...}</code> instead.]</p>
+<p>I read this RFC more as requesting a generic way to initialize an
+iterator according to the type of the iterator. The trick in this case
+is to prevent the re-evaluation of the spec every time -- you don't
+want to reopen the file every time you read a line from it, for
+instance. There will be standard ways to suppress evaluation in Perl 6,
+both from the standpoint of the caller and the callee. In any case, the
+model is that an anonymous subroutine is passed in, and called only
+when appropriate. So an iterator syntax might prototype its argument to
+be an anonymous sub, or the user might explicitly pass an anonymous
+sub, or both. In any event, the <code>sub</code> keyword will be optional in Perl
+6, so things like:</p>
+<pre> while (file {LIST}) { ... }</pre>
+<p>can be made to defer evaluation of LIST to the appropriate moment (or
+moments, if LIST is in turn generating itself on the fly). For
+appropriate parameter declarations I suppose even the brackets could be
+<a name='Properties'></a><h1>Properties</h1>
+<p>Variables and values of various types have various kinds of data
+attributes that are naturally associated with them by virtue of their
+type. You know a dog comes equipped with a wag, hopefully attached to a
+tail. That's just part of doghood.</p>
+<p>Many times, however, you want the equivalent of a Post-It(r) note, so
+you can temporarily attach bits of arbitrary information to some
+unsuspecting appliance that (though it wasn't designed for it) is
+nevertheless the right place to put the note. Similarly, variables and
+values in Perl 6 allow you to attach arbitrary pieces of information
+known as &quot;properties.&quot; In essence, any object in Perl can have an
+associated hash containing these properties, which are named by the
+hash key.</p>
+<p>Some of these properties are known at compile time, and don't actually
+need to be stored with the object in question, but can actually be
+stored instead in the symbol table entry for the variable in question.
+(Perl still makes it appear as though these values are attached to the
+object.) Compile-time properties can therefore be attached to variables
+of any type.</p>
+<p>[Update: Compile-time properties are now known as &quot;traits&quot;.]</p>
+<p>Run-time properties really are associated with the object in question,
+which implies some amount of overhead. For that reason, intrinsic data
+types like <code>int</code> and <code>num</code> may or may not allow run-time properties.
+In cases where it is allowed, the intrinsic type must generally be
+promoted to its corresponding object type (or wrapped in an object that
+delegates back to the original intrinsic for the actual value). But you
+really don't want to promote an array of a million bits to an array of
+a million objects just because you had the hankering to put a sticky
+note on one of those bits, so in those cases it's likely to be
+disallowed, or the bit is likely to be cloned instead of referenced, or
+some such thing.</p>
+<p>Properties may also be attached to subroutines.</p>
+<p>In general, you don't set or clear properties directly -- instead you
+call an accessor method to do it for you. If there is no method of that
+name, Perl will assume there was one that just sets or clears a
+property with the same name as the method. However, using accessor
+methods to set or clear properties allows us to define synthetic
+properties. For instance, there might be a real <code>constant</code> property
+that you could attach to a variable. Certain variables (such as those
+in a function prototype) might have <code>constant</code> set by default. In that
+case, setting a synthetic property such as <code>rw</code> might clear the
+underlying <code>constant</code> property.</p>
+<p>A property may be attached to the foregoing expression by means of the
+&quot;is&quot; keyword. Here's a compile-time property set on a variable:</p>
+<pre> my int $pi is constant = 3;</pre>
+<p>Here's a run-time property set on a return value:</p>
+<pre> return 0 is true;</pre>
+<p>[Update: Run-time properties are set with <code>but</code> rather than <code>is</code>.
+They're really just mixins. And there is no &quot;constant&quot; trait, but
+rather a &quot;readonly&quot; trait. Use the special declarator</p>
+<pre> constant int $pi = 3;</pre>
+<p>to declare a compile-time constant.]</p>
+<p>Whether a property is applied to a variable at compile time or a value
+at run-time depends on whether it's in lvalue or rvalue context.
+(Variable declarations are always in lvalue context even when you don't
+assign anything to them.)</p>
+<p>The &quot;<code>is</code>&quot; works just like the &quot;<code>.</code>&quot; of a method call, except
+that the return value is the object on the left, not the return value
+of the method, which is discarded.</p>
+<p>As it happens, the &quot;<code>is</code>&quot; is optional in cases where an operator is
+already expected. So you might see things like:</p>
+<pre> my int $pi constant = 3;
+ return 0 true;</pre>
+<p>In this case, the methods are actually being parsed as postfix
+operators. (However, we may make it a stricture that you may omit the
+<code>is</code> only for predeclared property methods.)</p>
+<p>[Update: the <code>is</code> or <code>but</code> is never optional.]</p>
+<p>Since these actually are method calls, you can pass arguments in
+addition to the object in question:</p>
+<pre> my int @table is dim(366,24,60);</pre>
+<p>[Update: that should be <code>my int @table[^366;^24;^60];</code> according to S09...]</p>
+<p>Our examples above are assuming an argument of <code>(1)</code>:</p>
+<pre> my int $pi is constant(1) = 3;
+ return 0 is true(1);</pre>
+<p>Since the &quot;<code>is</code>&quot; is optional in the common cases, you can stack
+multiple properties without repeating the &quot;<code>is</code>.&quot;</p>
+<pre> my int $pi is shared locked constant optimize($optlevel) = 3;</pre>
+<p>[Update: the <code>is</code> is no longer optional.]</p>
+<p>(Note that these methods are called on the <code>$pi</code> variable at compile
+time, so it behooves you to make sure everything you call is defined.
+For instance, <code>$optlevel</code> needs to be known at compile-time.)</p>
+<p>Here are a list of property ideas stolen from Damian. (I guess that
+makes it intellectual property theft.) Some of the names have been
+changed to protect the (CS) innocent.</p>
+<pre> # Subroutine attributes...
+ sub name is rw { ... } # was lvalue
+ my sub rank is same { ... } # was memoized
+ $snum = sub is optimize(1) { ... }; # &quot;is&quot; required here
+ # Variable attributes...
+ our $age is constant = 21; # was const
+ my %stats is private;
+ my int @table is dim(366,24,60);
+ $arrayref = [1..1000000] is computed Purpose('demo of anon var attrs');
+ sub choose_rand (@list is lazy) { return $list[rand @list] }
+ # &amp;@list notation is likely
+ $self = $class.bless( {name=&gt;$name, age=&gt;$age} is Initialized );
+ # Reference attributes...
+ $circular = \$head is weak;
+ # Literal attributes...
+ $name = &quot;Damian&quot; is Note(&quot;test data only&quot;);
+ $iohandle = open $filename is dis(qw/para crlf uni/) or die;
+ $default = 42 is Meaning(&lt;&lt;OfLife);
+ The Answer
+ OfLife
+ package Pet is interface;
+ class Dog inherits('Canine') { ... }
+ print $data{key is NoteToSelf('gotta get a better name for this key')};</pre>
+<p>(I don't agree with using properties for all of these things, but it's
+pretty amazing how far into the ground you can drive it.)</p>
+<p>Property names should start with an identifier letter (which includes
+Unicode letters and ideographs). The parsing of the arguments (if any)
+is controlled by the signature of the method in question. Property
+method calls without a &quot;.&quot; always modify their underlying property.</p>
+<p>[Update: the signature has nothing to do with how they're parsed. If
+a property has an argument it must follow without an intervening space.
+However, other brackets are allowed, and using <code>will</code> rather than <code>is</code>
+allows you to specify a closure with an intervening space.]</p>
+<p>If called as an ordinary method (with a &quot;.&quot;), the property value is
+returned without being modified. That value could then be modified by a
+run-time property. For instance, <code>$pi.constant</code> would return <code>1</code>
+rather than the value of <code>$pi</code>, so we get:</p>
+<pre> return $pi.constant is false; # &quot;1 but false&quot; (not possible in Perl 5)</pre>
+<p>On the other hand, if you omit the dot, something else happens:</p>
+<pre> return $pi constant is false; # 3 but false (and 3 is now very constant)</pre>
+<p>[Update: The dot form is only for access of properties and traits that
+are already there.]</p>
+<p>Here are some more munged Damian examples:</p>
+<pre> if (&amp; { ... }
+ $age++ unless $age.constant;
+ $elements = return reduce $^ * $^, *@table.dim;
+ last if ${self}.Initialized;
+ print &quot;$arrayref.Purpose() is not $default.Meaning()\n&quot;;
+ print %{$self.X}; # print hash referred to by X attribute of $self
+ print %{$self}.X; # print X attribute of hash referred to by $self
+ print %$self.X; # print X attribute of hash referred to by $self</pre>
+<p>As with the dotless form, if there is no actual method corresponding to
+the property, Perl pretends there's a rudimentary one returning the
+actual property.</p>
+<p>[Update: Actually, they are real method calls now, and properties and
+traits are really mixins. See A12.]</p>
+<p>Since these methods return the properties (except when overridden by
+dotless syntax), you can temporize a property just as you can any
+method, provided the method itself allows writing:</p>
+<pre> temp $self.X = 0;</pre>
+<p>Note that</p>
+<pre> temp $self is X = 0;</pre>
+<p>would assign to 0 to <code>$self</code> instead. (Whether it actually makes sense
+to set the compile-time X property at run time on the <code>$self</code> variable
+is anybody's guess.)</p>
+<p>Note that by virtue of their syntax, properties cannot be set by
+interpolation into a string. So, happily:</p>
+<pre> print &quot;My $variable is foobar\n&quot;;</pre>
+<p>does not attempt to set the <code>foobar</code> property on <code>$variable</code>.</p>
+<p>The &quot;<code>is</code>&quot; keyword binds with the same precedence as &quot;.&quot;, even
+when it's not actually there.</p>
+<p>[Update: Actually, <code>but</code> now has the precedence of other non-chaining
+operators, such as <code>..</code>. Since <code>is</code> occurs only in declarations, it
+is not subject to operator precedence at all.]</p>
+<p>Note that when you say <code>$</code>, you get <code>$foo</code>'s compile-time
+property if there is one (which is known at compile time, duh).
+Otherwise it's an ordinary method call on the value (which looks for a
+run-time property only if a method can't be found, so it shouldn't
+impact ordinary method call overhead.)</p>
+<p>[Update: No, that's always an ordinary method call now. Use
+<code>variable($foo).bar</code> to get at a property of the variable, or to call
+any other method on the variable object rather than the referent
+of <code>$foo</code>.]</p>
+<p>To get to the properties directly without going through the method
+interface, use the special <code>btw</code> method, which returns a hash ref to
+the properties hash.</p>
+<pre> $foo.btw{constant}</pre>
+<p>Note that synthetic properties won't show up there!</p>
+<p>[Update: there is no such hash anymore, and synthetic properties
+are simply synthetic methods.]</p>
+<p>None of the property names in this Apocalypse should be taken as final.
+We will decide on actual property names as we proceed through the
+<p>Well, that's it for Apocalypse 2. Doubtless there are some things I
+should have decided here that I didn't yet, but at least we're making
+progress. Well, at least we're moving in some direction or other. Now
+it's time for us to dance the Apocalypso, in honor of Jon Orwant and
+his new wife.</p>
913 source/archive/doc/design/apo/A03.html
@@ -0,0 +1,913 @@
+[% setvar title Apocalypse 3: Operators %]
+<h3>This file is part of the Perl 6 Archive</h3>
+ <p>To see what is currently happening visit <a href=""></a></p>
+<div class='pod'>
+<pre>=encoding utf-8</pre>
+<a name='TITLE'></a><h1>TITLE</h1>
+<p>Apocalypse 3: Operators</p>
+<a name='AUTHOR'></a><h1>AUTHOR</h1>
+<p>Larry Wall &lt;<a href=''></a>&gt;</p>
+<a name='VERSION'></a><h1>VERSION</h1>
+<pre> Maintainer: Larry Wall &lt;<a href=''></a>&gt;
+ Date: 2 Oct 2001
+ Last Modified: 18 May 2006
+ Number: 3
+ Version: 3</pre>
+<p>To me, one of the most agonizing aspects of language design is coming
+up with a useful system of operators. To other language designers, this
+may seem like a silly thing to agonize over. After all, you can view
+all operators as mere syntactic sugar -- operators are just funny
+looking function calls. Some languages make a feature of leveling all
+function calls into one syntax. As a result, the so-called functional
+languages tend to wear out your parenthesis keys, while OO languages
+tend to wear out your dot key.</p>
+<p>But while your computer really likes it when everything looks the same,
+most people don't think like computers. People prefer different things
+to look different. They also prefer to have shortcuts for common tasks.
+(Even the mathematicians don't go for complete orthogonality. Many of
+the shortcuts we typically use for operators were, in fact, invented by
+mathematicians in the first place.)</p>
+<p>So let me enumerate some of the principles that I weigh against each
+other when designing a system of operators.</p>
+<li><a name='Different classes of operators should look different. That's why filetest operators look different from string or numeric operators.'></a>Different classes of operators should look different. That's
+why filetest operators look different from string or numeric operators.</li>
+<li><a name='Similar classes of operators should look similar. That's why the filetest operators look like each other.'></a>Similar classes of operators should look similar. That's why
+the filetest operators look like each other.</li>
+<li><a name='Common operations should be &quot;Huffman coded.&quot; That is, frequently used operators should be shorter than infrequently used ones. For how often it's used, the scalar operator of Perl 5 is too long, in my estimation.'></a>Common operations should be &quot;Huffman coded.&quot; That is,
+frequently used operators should be shorter than infrequently used
+ones. For how often it's used, the <code>scalar</code> operator of Perl 5 is too
+long, in my estimation.</li>
+<li><a name='Preserving your culture is important. So Perl borrowed many of its operators from other familiar languages. For instance, we used Fortran's ** operator for exponentiation. As we go on to Perl 6, most of the operators will be &quot;borrowed&quot; directly from Perl 5.'></a>Preserving your culture is important. So Perl borrowed many of
+its operators from other familiar languages. For instance, we used
+Fortran's <code>**</code> operator for exponentiation. As we go on to Perl 6,
+most of the operators will be &quot;borrowed&quot; directly from Perl 5.</li>
+<li><a name='Breaking out of your culture is also important, because that is how we understand other cultures. As an explicitly multicultural language, Perl has generally done OK in this area, though we can always do better. Examples of cross-cultural exchange among computer cultures include XML and Unicode. (Not surprisingly, these features also enable better cross-cultural exchange among human cultures -- we sincerely hope.)'></a>Breaking out of your culture is also important, because that is
+how we understand other cultures. As an explicitly multicultural
+language, Perl has generally done OK in this area, though we can always
+do better. Examples of cross-cultural exchange among computer cultures
+include XML and Unicode. (Not surprisingly, these features also enable
+better cross-cultural exchange among human cultures -- we sincerely
+<li><a name='Sometimes operators should respond to their context. Perl has many operators that do different but related things in scalar versus list context.'></a>Sometimes operators should respond to their context. Perl has
+many operators that do different but related things in scalar versus
+list context.</li>
+<li><a name='Sometimes operators should propagate context to their arguments. The x operator currently does this for its left argument, while the short-circuit operators do this for their right argument.'></a>Sometimes operators should propagate context to their
+arguments. The <code>x</code> operator currently does this for its left argument,
+while the short-circuit operators do this for their right argument.</li>
+<li><a name='Sometimes operators should force context on their arguments. Historically, the scalar mathematical operators of Perl have forced scalar context on their arguments. One of the RFCs discussed below proposes to revise this.'></a>Sometimes operators should force context on their arguments.
+Historically, the scalar mathematical operators of Perl have forced
+scalar context on their arguments. One of the RFCs discussed below
+proposes to revise this.</li>
+<li><a name='Sometimes operators should respond polymorphically to the types of their arguments. Method calls and overloading work this way.'></a>Sometimes operators should respond polymorphically to the types
+of their arguments. Method calls and overloading work this way.</li>
+<li><a name='Operator precedence should be designed to minimize the need for parentheses. You can think of the precedence of operators as a partial ordering of the operators such that it minimizes the number of &quot;unnatural&quot; pairings that require parentheses in typical code.'></a>Operator precedence should be designed to minimize the need for
+parentheses. You can think of the precedence of operators as a partial
+ordering of the operators such that it minimizes the number of
+&quot;unnatural&quot; pairings that require parentheses in typical code.</li>
+<li><a name='Operator precedence should be as simple as possible. Perl's precedence table currently has 24 levels in it. This might or might not be too many. We could probably reduce it to about 18 levels, if we abandon strict C compatibility of the C-like operators.'></a>Operator precedence should be as simple as possible. Perl's
+precedence table currently has 24 levels in it. This might or might not
+be too many. We could probably reduce it to about 18 levels, if we
+abandon strict C compatibility of the C-like operators.</li>
+<li><a name='People don't actually want to think about precedence much, so precedence should be designed to match expectations. Unfortunately, the expectations of someone who knows the precedence table won't match the expectations of someone who doesn't. And Perl has always catered to the expectations of C programmers, at least up till now. There's not much one can do up front about differing cultural expectations.'></a>People don't actually want to think about precedence much, so
+precedence should be designed to match expectations. Unfortunately, the
+expectations of someone who knows the precedence table won't match the
+expectations of someone who doesn't. And Perl has always catered to the
+expectations of C programmers, at least up till now. There's not much
+one can do up front about differing cultural expectations.</li>
+<p>It would be easy to drive any one of these principles into the ground,
+at the expense of other principles. In fact, various languages have
+done precisely that.</p>
+<p>My overriding design principle has always been that the complexity of
+the solution space should map well onto the complexity of the problem
+space. Simplification good! Oversimplification bad! Placing artificial
+constraints on the solution space produces an impedence mismatch with
+the problem space, with the result that using a language that is
+artificially simple induces artificial complexity in all solutions
+written in that language.</p>
+<p>One artificial constraint that all computer languages must deal with is
+the number of symbols available on the keyboard, corresponding roughly
+to the number of symbols in ASCII. Most computer languages have
+compensated by defining systems of operators that include digraphs,
+trigraphs, and worse. This works pretty well, up to a point. But it
+means that certain common unary operators cannot be used as the end of
+a digraph operator. Early versions of C had assignment operators in the
+wrong order. For instance, there used to be a <code>=-</code> operator. Nowadays
+that's spelled <code>-=</code>, to avoid conflict with unary minus.</p>
+<p>By the same token (no pun intended), you can't easily define a unary
+<code>=</code> operator without requiring a space before it most of the time,
+since so many binary operators end with the <code>=</code> character.</p>
+<p>Perl gets around some of these problems by keeping track of whether it
+is expecting an operator or a term. As it happens, a unary operator is
+simply one that occurs when Perl is expecting a term. So Perl could
+keep track of a unary <code>=</code> operator, even if the human programmer might
+be confused. So I'd place a unary <code>=</code> operator in the category of
+&quot;OK, but don't use it for anything that will cause widespread
+confusion.&quot; Mind you, I'm not proposing a specific use for a unary
+<code>=</code> at this point. I'm just telling you how I think. If we ever do get
+a unary <code>=</code> operator, we will hopefully have taken these issues into
+<p>[Update: We currently have a <code>prefix:&lt;=&gt;</code> that iterates an iterator.]</p>
+<p>While we can disambiguate operators based on whether an operator or a
+term is expected, this implies some syntactic constraints as well. For
+instance, you can't use the same symbol for both a postfix operator and
+a binary operator. So you'll never see a binary <code>++</code> operator in Perl,
+because Perl wouldn't know whether to expect a term or operator after
+that. It also implies that we can't use the &quot;juxtaposition&quot; operator.
+That is, you can't just put two terms next to each other, and expect
+something to happen (such as string concatenation, as in <i>awk</i>). What
+if the second term started with something looked like an operator? It
+would be misconstrued as a binary operator.</p>
+<p>[Update: We now distinguish postfix operators from infix by the presence
+or absence of whitespace.]</p>
+<p>Well, enough of these vague generalities. On to the vague specifics.</p>
+<p>The RFCs for this apocalypse are (as usual) all over the map, but don't
+cover the map. I'll talk first about what the RFCs do cover, and then
+about what they don't. Here are the RFCs that happened to get
+themselves classified into chapter 3:</p>
+<pre> RFC PSA Title
+ --- --- -----
+ 024 rr Data types: Semi-finite (lazy) lists
+ 025 dba Operators: Multiway comparisons
+ 039 rr Perl should have a print operator
+ 045 bbb C&lt;||&gt; and C&lt;&amp;&amp;&gt; should propagate result context to both sides
+ 054 cdr Operators: Polymorphic comparisons
+ 081 abc Lazily evaluated list generation functions
+ 082 abc Arrays: Apply operators element-wise in a list context
+ 084 abb Replace =&gt; (stringifying comma) with =&gt; (pair constructor)
+ 104 ccr Backtracking
+ 138 rr Eliminate =~ operator.
+ 143 dcr Case ignoring eq and cmp operators
+ 170 ccr Generalize =~ to a special &quot;apply-to&quot; assignment operator
+ 283 ccc C&lt;tr///&gt; in array context should return a histogram
+ 285 acb Lazy Input / Context-sensitive Input
+ 290 bbc Better english names for -X
+ 320 ccc Allow grouping of -X file tests and add C&lt;filetest&gt; builtin</pre>
+<p>Note that you can click on the following RFC titles to view a copy of
+the RFC in question. The discussion sometimes assumes that you've read
+the RFC.</p>
+<a name='RFC 025: Operators: Multiway comparisons'></a><h2>RFC 025: Operators: Multiway comparisons</h2>
+<p>This RFC proposes that expressions involving multiple chained
+comparisons should act like mathematician would expect. That is, if you
+say this:</p>
+<pre> 0 &lt;= $x &lt; 10</pre>
+<p>it really means something like:</p>
+<pre> 0 &lt;= $x &amp;&amp; $x &lt; 10</pre>
+<p>The <code>$x</code> would only be evaluated once, however. (This is very much
+like the rewrite rule we use to explain assignment operators such as
+<code>$x += 3</code>.)</p>
+<p>I started with this RFC simply because it's not of any earthshaking
+importance whether I accept it or not. The tradeoff is whether to put
+some slight complexity into the grammar in order to save some slight
+complexity in some Perl programs. The complexity in the grammar is not
+much of a problem here, since it's amortized over all possible uses of
+it, and it already matches the known psychology of a great number of
+<p>There is a potential interaction with precedence levels, however. If we
+choose to allow an expression like:</p>
+<pre> 0 &lt;= $x == $y &lt; 20</pre>
+<p>then we'll have to unify the precedence levels of the comparison
+operators with the equality operators. I don't see a great problem with
+this, since the main reason for having them different was (I believe)
+so that you could write an exclusive of two comparisons, like this:</p>
+<pre> $x &lt; 10 != $y &lt; 10</pre>
+<p>However, Perl has a built-in <code>xor</code> operator, so this isn't really much
+of an issue. And there's a lot to be said for forcing parentheses in
+that last expression anyway, just for clarity. So unless anyone comes
+up with a large objection that I'm not seeing, this RFC is accepted.</p>
+<a name='RFC 320: Allow grouping of -X file tests and add filetest builtin'></a><h2>RFC 320: Allow grouping of -X file tests and add <code>filetest</code>
+<p>This RFC proposes to allow clustering of file test operators much like
+some Unix utilities allow bundling of single character switches. That
+is, if you say:</p>
+<pre> -drwx $file</pre>
+<p>it really means something like:</p>
+<pre> -d $file &amp;&amp; -r $file &amp;&amp; -w $file &amp;&amp; -x $file</pre>
+<p>Unfortunately, as proposed, this syntax will simply be too confusing.
+We have to be able to negate named operators and subroutines. The
+proposed workaround of putting a space after a unary minus is much too
+onerous and counterintuitive, or at least countercultural.</p>
+<p>The only way to rescue the proposal would be to say that such operators
+are autoloaded in some fashion; any negated but <i>unrecognized</i>
+operator would then be assumed to be a clustered filetest. This would
+be risky in that it would prevent Perl from catching misspelled
+subroutine names at compile time when negated, and the error might well
+not get caught at run time either, if all the characters in the name
+are valid filetests, and if the argument can be interpreted as a
+filename or filehandle (which is usually). Perhaps it would be
+naturally disallowed under <code>use strict</code>, since we'd basically be
+treating <code>-xyz</code> as a bareword. On the other hand, in Perl 5, <i>all</i>
+method names are essentially in the unrecognized category until run
+time, so it would be impossible to tell whether to parse the minus sign
+as a real negation. Optional type declarations in Perl 6 would only
+help the compiler with variables that are actually declared to have a
+type. Fortunately, a negated 1 is still true, so even if we parsed the
+negation as a real negation, it might still end up doing the right
+thing. But it's all very tacky.</p>
+<p>So I'm thinking of a different tack. Instead of bundling the letters:</p>
+<pre> -drwx $file</pre>
+<p>let's think about the trick of returning the value of <code>$file</code> for a
+true value. Then we'd write nested unary operators like this:</p>
+<pre> -d -r -w -x $file</pre>
+<p>One tricky thing about that is that the operators are applied right to
+left. And they don't really short circuit the way stacked <code>&amp;&amp;</code> would
+(though the optimizer could probably fix that). So I expect we could do
+this for the default, and if you want the <code>-drwx</code> as an autoloaded
+backstop, you can explicitly declare that.</p>
+<p>In any event, the proposed <code>filetest</code> built-in need not be built in.
+It can just be a universal method. (Or maybe just common to strings and
+<p>My one hesitation in making cascading operators work like that is that
+people might be tempted to get cute with the returned filename:</p>
+<pre> $handle = open -r -w -x $file or die;</pre>
+<p>That might be terribly confusing to a lot of people. The solution to
+this conundrum is presented at the end of the next section.</p>
+<a name='RFC 290: Better english names for -X'></a><h2>RFC 290: Better english names for -X</h2>
+<p>This RFC proposes long names as aliases for the various filetest
+operators, so that instead of saying:</p>
+<pre> -r $file</pre>
+<p>you might say something like:</p>
+<pre> use english;
+ freadable($file)</pre>
+<p>Actually, there's no need for the <code>use english</code>, I expect. These names
+could merely universal (or nearly universal) methods. In any case, we
+should start getting used to the idea that <code>mumble($foo)</code> is
+equivalent to <code>$foo.mumble()</code>, at least in the absence of a local
+subroutine definition to the contrary. So I expect that we'll see both:</p>
+<pre> is_readable($file)</pre>
+<pre> $file.is_readable</pre>
+<p>Similar to the cascaded filetest ops in the previous section, one
+approach might be that the boolean methods return the object in
+question for success so that method calls could be stacked without
+repeating the object:</p>
+<pre> if ($file.is_dir
+ .is_readable
+ .is_writable
+ .is_executable) {</pre>
+<p>[Update: the syntax above is now illegal.]</p>
+<p>But <code>-drwx $file</code> could still be construed as more readable, for some
+definition of readability. And cascading methods aren't really
+short-circuited. Plus, the value returned would have to be something
+like &quot;$file is true,&quot; to prevent confusion over filename &quot;0.&quot;</p>
+<p>There is also the question of whether this really saves us anything
+other than a little notational convenience. If each of those methods
+has to do a <i>stat</i> on the filename, it will be rather slow. To fix
+that, what we'd actually have to return would be not the filename, but
+some object containing the stat buffer (represented in Perl 5 by the
+<code>_</code> character). If we did that, we wouldn't have to play <code>$file is
+true</code> games, because a valid stat buffer object would (presumably)
+always be true (at least until it's false).</p>
+<p>The same argument would apply to cascaded filetest operators we talked
+about earlier. An autoloaded <code>-drwx</code> handler would presumably be smart
+enough to do a single stat. But we'd likely lose the speed gain by
+invoking the autoload mechanism. So cascaded operators (either <code>-X</code>
+style or <code>.is_XXX</code> style) are the way to go. They just return objects
+that know how to be either boolean or stat buffer objects in context.
+This implies you could even say</p>
+<pre> $statbuf = -f $file or die &quot;Not a regular file: $file&quot;;
+ if (-r -w $statbuf) { ... }</pre>
+<p>This allows us to simplify the special case in Perl 5 represented by
+the <code>_</code> token, which was always rather difficult to explain. And
+returning a stat buffer instead of <code>$file</code> prevents the confusing:</p>
+<pre> $handle = open -r -w -x $file or die;</pre>
+<p>Unless, of course, we decide to make a stat buffer object return the
+filename in a string context. <code>:-)</code></p>
+<a name='RFC 283: tr/// in array context should return a histogram'></a><h2>RFC 283: <code>tr///</code> in array context should return a histogram</h2>
+<p>Yes, but ...</p>
+<p>While it's true that I put that item into the Todo list ages ago, I
+think that histograms should probably have their own interface, since
+the histogram should probably be returned as a complete hash in scalar
+context, but we can't guess that they'll want a histogram for an
+ordinary scalar <code>tr///</code>. On the other hand, it could just be a <code>/h</code>
+modifier. But we've already done violence to <code>tr///</code> to make it do
+character counting without transliterating, so maybe this isn't so far
+<p>One problem with this RFC is that it does the histogram over the input
+rather than the output string. The original Todo entry did not specify
+this, but it was what I had intended. But it's more useful to do it on
+the resulting characters because then you can use the <code>tr///</code> itself
+to categorize characters into, say, vowels and consonants, and then
+count the resulting V's and C's.</p>
+<p>On the other hand, I'm thinking that the <code>tr///</code> interface is really
+rather lousy, and getting lousier every day. The whole <code>tr///</code>
+interface is kind of sucky for any sort of dynamically generated data.
+But even without dynamic data, there are serious problems. It was bad
+enough when the character set was just ASCII. The basic problem is that
+the notation is inside out from what it should be, in the sense that it
+doesn't actually show which characters correspond, so you have to count
+characters. We made some progress on that in Perl 5 when, instead of:</p>
+<pre> tr/abcdefghijklmnopqrstuvwxyz/VCCCVCCCVCCCCCVCCCCCVCCCCC/</pre>
+<p>we allowed you to say:</p>
+<pre> tr[abcdefghijklmnopqrstuvwxyz]
+<p>There are also shenanigans you can play if you know that duplicates on
+the left side prefer the first mention to subsequent mentions:</p>
+<pre> tr/aeioua-z/VVVVVC/</pre>
+<p>But you're still working against the notation. We need a more explicit
+way to put character classes into correspondence.</p>
+<p>More problems show up when we extend the character set beyond ASCII.
+The use of <code>tr///</code> for case translations has long been
+semi-deprecated, because a range like <code>tr/a-z/A-Z/</code> leaves out
+characters with diacritics. And now with Unicode, the whole notion of
+what is a character is becoming more susceptible to interpretation, and
+the <code>tr///</code> interface doesn't tell Perl whether to treat character
+modifiers as part of the base character. For some of the double-wide
+characters it's even hard to just <i>look</i> at the character and tell if
+it's one character or two. Counted character lists are about as modern
+as hollerith strings in Fortran.</p>
+<p>So I suspect the <code>tr///</code> syntax will be relegated to being just one
+quote-like interface to the actual transliteration module, whose main
+interface will be specified in terms of translation pairs, the left
+side of which will give a pattern to match (typically a character
+class), and the right side will say what to translation anything
+matching to. Think of it as a series of coordinated parallel <code>s///</code>
+operations. Syntax is still open for negotiation till apocalypse 5.</p>
+<p>But there can certainly be a histogram option in there somewhere.</p>
+<a name='RFC 084: Replace =&gt; (stringifying comma) with =&gt; (pair constructor)'></a><h2>RFC 084: Replace <code>=&gt;</code> (stringifying comma) with <code>=&gt;</code>
+(pair constructor)</h2>
+<p>I like the basic idea of pairs because it generalizes to more than just
+hash values. Named parameters will almost certainly be implemented
+using pairs as well.</p>
+<p>I do have some quibbles with the RFC. The proposed <code>key</code> and <code>value</code>
+built-ins should simply be lvalue methods on pair objects. And if we
+use pair objects to implement entries in hashes, the key must be
+immutable, or there must be some way of re-hashing the key if it
+<p>The stuff about using pairs for mumble-but-false is bogus. We'll use
+properties for that sort of chicanery. (And multiway comparisons won't
+rely on such chicanery in any event. See above.)</p>
+<a name='RFC 081: Lazily evaluated list generation functions'></a><h2>RFC 081: Lazily evaluated list generation functions</h2>
+<p>Sorry, you can't have the colon--at least, not without sharing it.
+Colon will be a kind of &quot;supercomma&quot; that supplies an adverbial list
+to some previous operator, which in this case would be the prior colon
+or dotdot.</p>
+<p>(We can't quite implement <code>?:</code> as a <code>:</code> modifier on <code>?</code>, because the
+precedence would be screwey, unless we limit <code>:</code> to a single argument,
+which would preclude its being used to disambiguate indirect objects.
+More on that later.)</p>
+<p>The RFC's proposal concerning <code>attributes::get(@a)</code> stuff is superseded
+by value properties. So, <code>@a.method()</code> should just pull out the
+variable's properties directly, if the variable is of a type that
+supports the methods in question. A lazy list object should certainly
+have such methods.</p>
+<p>Assignment of a lazy list to a tied array is a problem unless the tie
+implementation handles laziness. By default a tied array is likely to
+enforce immediate list evaluation. Immediate list evaluation doesn't
+work on infinite lists. That means it's gonna fill up your disk drive
+if you try to say something like:</p>
+<pre> @my_tied_file = 1..Inf;</pre>
+<p>Laziness should be possible, but not necessarily the norm. It's all
+very well to delay the evaluation of &quot;pure&quot; functions in the realm of
+math, since presumably you get the same result no matter when you
+evaluate. But a lot of Perl programming is done with real world data
+that changes over time. Saying <code>somefunc($a .. $b)</code> can get terribly
+fouled up if <code>$b</code> can change, and the lazy function still refers to
+the variable rather than its instantaneous value. On the other hand,
+there is overhead in taking snapshots of the current state.</p>
+<p>On the gripping hand, the lazy list object <i>is</i> the snapshot of the
+values, that's not a problem in this case. Forget I mentioned it.</p>
+<p>The tricky thing about lazy lists is not the lazy lists themselves, but
+how they interact with the rest of the language. For instance, what
+happens if you say:</p>
+<pre> @lazy = 1..Inf;
+ @lazy[5] = 42;</pre>
+<p>Is <code>@lazy</code> still lazy after it is modified? Do we remember the
+<code>@lazy[5]</code> is an &quot;exception&quot;, and continue to generate the rest of
+the values by the original rule? What if <code>@lazy</code> is going to be
+generated by a recursive function? Does it matter whether we've already
+generated <code>@lazy[5]</code>?</p>
+<p>And how do we explain this simply to people so that they can
+understand? We will have to be very clear about the distinction between
+the abstraction and the concrete value. I'm of the opinion that a lazy
+list is a definition of the <i>default</i> values of an array, and that the
+actual values of the array override any default values. Assigning to a
+previously memoized element overrides the memoized value.</p>
+<p>It would help the optimizer to have a way to declare &quot;pure&quot; array
+definitions that can't be overridden.</p>
+<p>Also consider this:</p>
+<pre> @array = (1..100, 100..10000:100);</pre>
+<p>A single flat array can have multiple lazy lists as part of it's
+default definition. We'll have to keep track of that, which could get
+especially tricky if the definitions start overlapping via slice
+<p>In practice, people will treat the default values as real values. If
+you pass a lazy list into a function as an array argument, the function
+will probably not know or care whether the values it's getting from the
+array are being generated on the fly or were there in the first place.</p>
+<p>I can think of other cans of worms this opens, and I'm quite certain
+I'm too stupid to think of them all. Nevertheless, my gut feeling is
+that we can make things work more like people expect rather than less.
+And I was always a little bit jealous that REXX could have arrays with
+default values. <code>:-)</code></p>
+<p>[Update: Turns out that all lists are lazy by default. Use the <code>eager</code> listop
+to force a non-lazy list evaluation immediately.]</p>
+<a name='RFC 285: Lazy Input / Context-sensitive Input'></a><h2>RFC 285: Lazy Input / Context-sensitive Input</h2>
+<p>Solving this with <code>want()</code> is the wrong approach, but I think the
+basic idea is sound because it's what people expect. And the <code>want()</code>
+should in fact be unnecessary. Essentially, if the right side of a list
+assignment produces a lazy list, and the left side requests a finite
+number of elements, the list generator will only produce enough to
+satisy the demand. It doesn't need to know how many in advance. It just
+produces another scalar value when requested. The generator doesn't
+have to be smart about its context. The motto of a lazy list generator
+should be, &quot;Ours is not to question why, ours is but to do (the next
+one) or die.&quot;</p>
+<p>It will be tricky to make this one work right:</p>
+<pre> ($first, @rest) = 1 .. Inf;</pre>
+<a name='RFC 082: Arrays: Apply operators element-wise in a list context'></a><h2>RFC 082: Arrays: Apply operators element-wise in a list context</h2>