Выдумывать свой язык программирования - это весёлое занятие. Я и сам порой люблю помечтать. Но возможно и другое направление мысли: русификация уже существующих ЯП. Это даёт ряд преимуществ. В частности возможность использовать готовые библиотеки (которые, правда, тоже нужно русифицировать).
Пока я встречал только проект русификации С.
Далее я рассматриваю ряд шагов, которые может проходить программа, написанная на русифицированном ЯП от ввода исходного кода, до исполняемого файла. Буду рад, если кого-то эта тема заинтересует.
Ввод текста программы.
Для удобной работы с кириллицей необходимо создать специальный текстовой редактор. Идея состоит в том, чтобы можно было вводить всякие закорючки не переключаясь всё время на латиницу. Для этого предлагаю использовать сочетания Контрол+ и Альт+. Например, для ввода символа «<» необходимо будет нажать Контрол+«Б», а для «,» Альт+«Б». Текстовой редактор выделяет цветом служебные слова, комментарии и т. п. Кроме того полезной будет функция дописывания слова при нажатии Контрол+Пробел. Т. е. при нажатии этого сочетания клавиш, редактор собирает по всему тексту уже введённые имена, прибавляет к ним имена из библиотек, сортирует и выдаёт соответствующие началу слова варианты.
Трансляция в целевой ЯП.
Служебные слова транслируются в соответствии со словарём служебных слов. В принципе этот словарь может быть реализован в виде текстового файла с записями вроде:
if если
else иначе
switch выбор
…
Тут есть некоторые тонкости. Например, в Java слово final используется в трёх ипостасях. В первом случае оно может пониматься как объявление константы. Т. е. русифицироваться как «конст». Во втором случае оно используется для предотвращения перекрытия и может быть переведено как «неперекр». И, наконец, предотвращает наследование класса и может быть переведено как «ненаслед». Хотя это под вопросом, стоит ли вводить зоопарк имён или всегда заменять final на «заверш». Всё это я к чему. В словаре может быть несколько вариантов перевода, например:
final конст
final неперекр
final ненаслед
Имена переменных транслируются в транслит. Я изучил разные системы транслитерации. Там либо используются буквы, которых нет на клавиатуре, либо используются кавычки вместо твёрдого и мягкого знака. Поэтому предлагаю следующую систему трансляции кириллицы на латиницу:
А - A
Б - B
В - V
Г - G
Д - D
Е - E
Ё – OQ
Ж - GQ
З - Z
И - I
Й - J
К - K
Л - L
М - M
Н - N
О - O
П - P
Р - R
С - S
Т - T
У - U
Ф - F
Х - X
Ц - C
Ч - CQ
Ш - H
Щ - HQ
Ь - W
Ы - Y
Ъ - WQ
Э - EQ
Ю - UQ
Я - AQ
При такой системе кодирования можно однозначно переводить кириллицу в латиницу и обратно. Вот пример текста на транслите:
Rusifikacyaq, o kotoroj tak dolgo govorili programmisty, sverhilasw!
В случае с языком программирования переведённое имя будет начинаться с «qqq», вот несколько примеров:
ДлиннаФайла - qqqDlinnaFajla
УказательЗапроса - qqqUkazatelwZaprosa
СтроковойБуфер - qqqStrokovojBufer
Имена библиотек, библиотечных классов, функций и т. д. транслируются в соответствии со словарём библиотечных объектов. Кто и как будет формировать этот словарь, под большим вопросом. Как идеальный вариант, предположим, что у нас есть некоторый сервер где в базе данных хранится весь словарь. Если кто-то захочет использовать библиотеку, которая ещё не русифицирована, он может самостоятельно её перевести и пополнить словарь. В реальности, скорее всего, будет множество словарей, созданных разными авторами. Словари можно будет хранить, и передавать вместе с исходным кодом.
Следует обратить внимание, что при трансляции имён, словарь библиотечных объектов имеет больший приоритет по сравнению с переводом на транслит. Предположим, что нам захотелось завести целочисленную переменную с именем «длинна»:
цел длинна;
В словаре библиотечных объектов наверняка уже есть перевод этого слова:
length - длинна
поэтому вышеприведённый текст будет оттранслирован как:
int length;
а не как:
int qqqdlinna;
Компиляция после трансляции производится как обычно.
Значительную проблему представляет русификация сообщений об ошибках и предупреждений. Для некоторых реализаций ЯП достать список ошибок не так-то просто. Кроме того, разные сообщения могут иметь разный формат, поэтому русификация сообщений это довольно кропотливый труд. Да, и ещё, есть ведь ошибки времени выполнения.
