RFC  PSA  Title
---  ---  -----
  Исходный код
005  cdr  Многострочные комментарии в Perl.
102  dcr  «Встроенные» комментарии в Perl.

  Типы данных
161  adb  В Perl все становится объектом.
038  bdb  Стандартизировать обработку 
          «неправильных» чисел, таких как 
          бесконечность и NaN.
043  bcb  Встроить поддержку BigInt (и BigRat) в скаляры.
192  ddr  Значение Undef не равно ни одному другому 
          значению.
212  rrb  Сделать, чтобы length() работала для массивов.
218  bcc  Конструкция проверки типа my Dog $spot.

  Переменные
071  aaa  Запретить синтаксис $пакет'переменная.
009  bfr  «Высокогорные» типы переменных.
133  bcr  Альтернативный синтаксис для имен переменных.
134  bcc  Другой синтаксис срезов массивов и хэшей.
196  bcb  Более прямой синтаксис для хэшей.
201  bcr  Срезы хэшей.

  Строки
105  aaa  Отключить ошибку "In string @ must be \@".
111  aaa  Ограничители here-документов.
162  abb  Содержимое here-документов.
139  cfr  Вызов специальных функций наподобие s///.
222  abb  Интерполяция вызовов методов объекта.
226  acr  Выборочная интерполяция строк в апострофах.
237  adc  Хэши интерполируются для строк в кавычках.
251  acr  Интерполяция вызовов функций классов.
252  abb  Интерполяция обычных функций.
327  dbr  Знак \v для вертикальной табуляции.
328  bcr  Апострофы не интерполируют \ и \\.

  Файлы
034  aaa  Угловые скобки не должны использоваться для 
          получения содержимого директории.
051  ccr  Угловые скобки должны понимать имена 
          файлов и списки.

  Списки
175  rrb  Добавить ключевой слово «list» для 
          форсирования спискового контекста (по 
          аналогии со scalar).

  Отклоненное
010  rr   Файловые переменные должны использовать * 
          как префикс типа, если typeglob-ы будут 
          устранены.
103  rr   Исправить старшинство $pkg::$var.
109  rr   Меньше пунктуации в строке, или 
          почему бы не избавиться от @%.
245  rr   Добавить ключевое слово empty в DWIM 
          для очистки переменных.
263  rr   Добавить ключевое слово Null и 
          фундаментальный тип данных.

Атомы

Вообще говоря, компоненты Perl 6 написаны с применением Unicode, и код подразумевает семантику Unicode даже в случае, если он обрабатывает «за кулисами» данные в другой кодировке. Нужно заметить, что, когда мы говорим: «Perl написан в Unicode», мы говорим об абстрактной таблице символов, а не конкретной кодировке. (Типичные программы, наверное, удобнее писать в UTF-8 на Западе и в какой-нибудь 16-битной кодировке — на Востоке).

Молекулы

RFC 005: Многострочные комментарии в Perl

Признаю, я имел предубеждения на счет комментариев — с молодости находился под незаконным влиянием рациональности языка Ada, где, как мне казалось, весьма разумно исключили многострочные комментарии.

Но даже если я бы и не был ослеплен своим предубеждением, мне казалось, что я подходил к вопросу с философской позиции и замечал, что в большинстве случаев, даже если язык имел многострочные комментарии, люди все же имеют тенденцию использовать их примерно вот так:

/*
 *  Вышел из тумана
 *  Месяц с лицом самурая.
 *  Обнажил меч из кармана кимоно.
 */

Контраргументом тут может быть факт, что люди не всегда делают так в Си, так что почему они должны страдать в Perl? И если нет другого способа делать многострочные комментарии в Perl, всем резко становится плохо. Однако другой способ все же есть, хотя он и отклонен в этом RFC как «обходной путь».

Вот он. Мне кажется, вместо того, чтобы добавлять в язык новый тип комментариев или создавать нечто, «работающее», как комментарий, нужно просто исправить все недостатки POD, чтобы его использование для комментирования уже нельзя было трактовать как «обходной путь». Дизайн POD мы отложим до 26-го Откровения, а сейчас мы можем лишь взвесить способы переключения с Perl на POD и обратно для комментирования. Итак, в Perl 6 мы имеем правило: если =begin ТраЛяЛя переводит в режим комментирования, то соответствующий =end ТраЛяЛя должен вернуть нас обратно в Perl (без директивы =cut).

Нужно заметить, что общий вид этих самых ТраЛяЛа еще не утвержден, однако уже сейчас можно утверждать: такие конструкции можно будет использовать для программного доступа к тексту комментариев. Хорошая возможность для грамотных (или хотя бы полуграмотных) интергированных систем программирования и разработки.

RFC 102: «Встроенные» комментарии в Perl

Я никогда особо не любил «встроенные» комментарии (наподобие /* ... */ в Си, расположенные в середине строки) — как правило, они больше запутывают код. Я не против, если вы их определите. То есть, нет ничего, что бы могло удерживать вас от написания лексического анализатора, способного обрабатывать «встроенные» комментарии, благо мы сделали анализатор Perl легко расширяемым. Такова наша воля. (Так вышло, что последовательность символов /* вряд ли когда будет носить управляющий характер в Perl 6. Догадываюсь, что она, наверное, появится в нестандартном Perl 6.)

Прагма, включающая «встроенные» комментарии, будет также позволять по желанию использовать /* */ в качестве многострочных комментариев. Но мне кажется, что для этих целей все же лучше подойдут директивы POD, позволяющие сделать текст комментариев доступным программе.

Встроенные типы данных

Главное нововведение Perl 6 заключается в том, что он, кроме скаляров, массивов и хэшей также поддерживает четвертый фундаментальный тип данных — «непрозрачный» (или абстрактный) объект. (Вы можете думать о нем примерно как о псевдохэше.) В то время как класс может иметь доступ к любым членам объекта своего типа, любой внешний доступ к абстрактным объектам происходит только через методы. Это касается и атрибутов (что гарантирует правильность работы механизма наследования).

Хотя Perl 6 все еще поддерживает типонезависимые скаляры, он позволяет программисту добиться лучшей производительности и надежности при указании типа данных, с которыми предстоит работать. Наблюдения показывают, что данные очень часто хранятся в массивах и хэшах, так что вы сможете задавать тип и для тех скаляров, которые содержатся в хэшах и массивах. Данные все еще могут храниться и в бестиповых массивах и хэшах, однако Perl 6 все же будет поощрять использовать для этих целей классы, точно так же, как Си поощряет использовать структуры вместо нескольких массивов.

Сейчас, забегая вперед, стоит упоминуть о понятии «свойство». (В Perl 6 свойства называют «атрибутами», однако мы зарезервировали этот термин для реальных атрибутов объекта, так что здесь употребляем слово «свойство».) Вкратце: переменные и значения могут иметь ассоциированный с ними блок данных, что расходится с общепринятыми представлениями о переменных. Сейчас вы можете представлять себе свойства как способ добавления в класс специальных атрибутов, которые он изначально не поддерживал. Вы также можете думать о них как о форме наследования с одновременной независимостью каждого объекта, без необходимости полного создания нового класса.

RFC 161: В Perl все становится объектом

По сути, этот RFC носит философский характер, и детали объясняются весьма скупо. Вообще, я согласен с утверждением, что все объекты Perl должны вести себя именно как объекты, если вы используете их в этом контексте. Если же вы захотите использовать их не как объекты, Perl также не будет против. (Вы можете использовать индексацию хэшей и синтаксис срезов для доступа к атрибутам, например, даже в том случае, если сами атрибуты не хранятся изначально в хэше.) Факт, что Perl 6 является более объектно-ориентированным языком на низком уровне, вовсе не означает, что вам придется «думать объектно-ориентированно», когда вы этого не хотите. (В целом, все же есть несколько вещей в Perl 6, где объектно-ориентированное мышление более необходимо, чем это было в Perl 5. К примеру, файловые дескрипторы Perl 6 более объектно-ориентированы, чем раньше, и специальные переменные для «магической» связи с текущим выбранным выходным потоком гораздо удобнее использовать в ассоциации с файловым дескриптором.)

Продолжение следует.