Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Прочее

Многоязыковое программирование

Представим такую ситуацию, что какой-то язык программирования даёт возможность одновременного использования естественных языков. Когда в одной программе вполне могут ужиться английский, русский, вьетнамский и любой другой язык. Тогда возможна такая ситуация, когда некое слово одного языка имеет тот же код, что и слово какого-то другого языка. Но имеет при этом совсем иной смысл.
Многоязыковое программирование
Например, в языке N слово «xyz» может означать «если», а в языке M оно может означать «цикл». Планируя многоязыковую поддержку в языке, следует учитывать потенциальную возможность конфликтных ситуаций. Русский язык и английский между собой не конфликтуют при использовании Unicode, ибо у них разные алфавиты. Но многие языки имеют одинаковые или пересекающиеся алфавиты. Как избежать конфликтных ситуаций?

            Язык программирования (или среда программирования) должен содержать команды подключения и отключения языков. Например, «подключить русский» или «отключить английский». Включение языка должно включать в себя подключение ключевых и служебных слов, классов, функций и всего прочего на указанном языке. Это можно сделать статически, когда перечень используемых языков известен к началу компиляции. Можно сделать и динамически, когда подключение и отключение языков делается прямо в тесте программы.
Программирование по-арабски


            Говоря о многоязыковой поддержке, нельзя не сказать о кодировке символов языков. Бесспорно, что наименьшее количество проблем может обеспечить только Unicode. О восьмибитной ASCII уже не стоит вспоминать, о реликтовых кодировках типа EBCDIC и МТК — тем более. UTF-8 непрактичен из-за того, что символы имеют неодинаковую длину. Подробнее эта тема обсуждена в статье «Выбор кодировки для компилятора».

            Теперь стоило бы разобраться, что следует понимать под подключением языка. Под этим можно подразумевать загрузку словаря ключевых слов на неком естественном языке. Но при этом можно оставить доступными все алфавиты. Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита.

            Возможен и второй вариант, когда подключение языков X, Y и Z означает подключение соответствующих словарей ключевых слов и алфавитов этих языков. При этом любые остальные алфавиты остаются под запретом.

Последняя правка: 2015-01-23    13:17

ОценитеОценки посетителей
   █████████████████████ 2 (50%)
   ███████████ 1 (25%)
   ███████████ 1 (25%)
   ▌ 0

Отзывы

     2014/07/21 03:41, utkin

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

Я считаю, что это непрактично и усложняет работу в команде. Ведь тогда, каждый программист, сталкивающийся с такими участками должен владеть двумя диалектами. В тоже время хороших профессионалов трудно найти и для одного. Решение проблемы описанной в задаче может заключаться в возможности IDE транслировать представление с одного диалекта на другой. Для имен переменных можно использовать транслитерацию (например в английский), для комментариев - онлайн-переводчики.

а UTF непрактичен из-за того, что символы имеют неодинаковую длину.

Это надуманная проблема. Работа алгоритма должна заключаться в расчетах в «символах» (и это логично и более понятно), а не в «байтах». Тут наверно психологический барьер, а не практический.

Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита.

Я категорически против смешения двух языков в одной программе. Еще раз напомню - команде разработчиков придется знать оба. Вероятность ошибок вырастает в разы.

     2016/03/26 17:16, rst256

Никакого совмещения, язык программирования, в отличие от естественного, по определению гарантирует однозначное и верное преобразование текста исходного кода с одного человеческого языка на другой, при наличии соответствующих словарей. Это даже на порядок проще, чем обработка этого же кода компиляцией.

Уровень регулярок. Словарики только обеспечите к каждому языку. И для каждого один и тот же текст программы будет на том языке, который он выбрал, а вот с идентификаторами уже не так все просто. Если для компилятора никаких особых проблем с идшниками на разных языках нет (только если вы не будете требовать транслитерации их с языка на язык!), они тупо должны быть уникальны и выделяемы из текста.

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

Как видите в техническом плане задача решается, и никаких проблем компилятору не создаст.

     2016/07/02 05:15, rst256

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

Еще раз: для чего таки нужна эта функция динамического отключения/подключения языка прямо в тесте программы? Такое многоязыковое программирование "is not useful", в нормальных проектах это функция будет строго запрещена, ну а в ненормальных... Впрочем я не могу представить себе, настолько ненормальные проекты должны быть проекты, чтобы бы такое разрешили!
В чем смысл то? Имеем код, который полностью понятен только лишь компилятору, т.к. директива смены языка на китайский традиционный увы не наделяет программиста из, скажем, Франции способностью бегло читать иероглифы! Представим такой диалог:
Босс: У вас там баг в коде строка №..., немедленно исправьте!
Программист: Это невозможно, сэр. Ту часть кода писал Ли Чен Янг, она на китайском, а он в отпуске. Для работы с той частью кода нужен программист владеющий КИТАЙСКИМ ДИАЛЕКТОМ языка ХХХ...

     2016/07/03 14:28, Автор сайта

В случае работы исключительно в IDE возможность переключения языков можно было бы делать через меню IDE. Компилятор же должен иметь и консольный вариант, поэтому директива загрузки языка – более правильный вариант. Французскому программисту сложновато будет понять иероглифы. Но ведь тут речь идёт и о словарях, которые позволят переводить тексты «на лету». Главное – чтобы они были. Чтобы с китайского можно было перевести на французский.

     2016/07/20 17:30, Alex

Уважаемые! Вы спорите, можно или нет совмещать несколько языков в одном проекте...

Я почти каждый день вынужден ковыряться в программах, которые имеют не только комментарии на разных языках, но и в разных кодировках! Одновременно! В соседних строках! Полагаю, что нужны текстовые редакторы, которые могли бы "переварить" такую мешанину, например, используя теги. Внутри текста, ограниченного конкретным тегом, ввод текста должен происходить в заданной кодировке и выбранным языком.

В некоторых ОСях есть переменная окружения LANGUAGE. Для дополнения к ней целесообразно сделать одноимённый подкаталог, в котором есть подкаталоги разных языков. А в них - что-то типа БД. Записи с одинаковым индексом имеют равный смысл. В результате при переключении на другой язык, вы сразу получаете новый набор идентификаторов для функций, переменных, классов, которые в IDE будут отображаться.

Если в строке программы вы зададите значение переменной LANGUAGE, то получите соответствующий набор слов. Вздумал перейти на русский - пожалуйста! Вся программа - на русском. Захотел японский - нет проблем!

А текстовый редактор, умеющий подстраиваться под теги, позволит в одном файле совместить (ну захотел конкретный программист именно такой стиль) англоязычный стандартный набор языка Си и русскоязычные переменные и некоторые функции. Мне бы в такой среде работать понравилось.

     2016/08/14 02:48, rst256

В случае работы исключительно в IDE возможность переключения языков можно было бы делать через меню IDE. Компилятор же должен иметь и консольный вариант, поэтому директива загрузки языка – более правильный вариант.

Уважаемый Автор, тут я с вами полностью согласен. Даже более не представляю себе компилятор в ином формате кроме, консольного приложения или библиотеки.

Но не в коде же! Аналогом меню в консоли является параметры командной строки, а не исходный код. И компилятор то как раз ни в каких иных языках, кроме собственного не нуждается. Если стоит задача, чтобы эти всевозможные языки "уживались" в одном коде, единственное средство добиться этого только одно. Выкинуть их полностью из кода! 100-200 функциональных лексем языка программирования против тысяч возможных способов их закодировать, не говоря уже про возможные конфликты идентификаторов. Так кого проще вынести из кода: естественный язык или программный? Машине не всё равно, это человеку будет всё равно, каким образом на экране появился именно такой текст, какой он желал бы увидеть без всяких анклавов на другом "языке" и прочих директив. Если я увижу хоть одного человека, который бы в зависимости от конкретной области кода менял бы свои "языковые" предпочтения, я сразу же соглашусь с тем, что горячая замена языка внутри кода необходима. Но тогда я в принципе не вижу возможности как избежать конфликтных ситуаций.

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

А если надо, чтобы исходник в вавилонскую башню превратился, тогда да – директивы в коде будут этому способствовать. И, возможно, в подключении конкретного алфавита нет необходимости. Оптимизированный алгоритм, который я вам скидывал, довольно легко справляется с поиском сразу по всем существующим в юникоде алфавитам. Он справляется с любым символом максимум за 10 простых итераций. И необходим только для внесения в древо новых слов.

Написать отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Устарел ли текст как форма представления программы

Русский язык и программирование

Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

Некоторые «вкусности» Алгол-68

«Двухмерный» синтаксис Python

Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

Должна ли программа быть удобочитаемой?

Стиль языка программирования

Тексто-графическое представление программы

●  Разделители

●  Строки программы

●  Слева направо или справа налево?

Комментарии

●  Длинные комментарии

●  Короткие комментарии

●  Комментарии автоматической генерации документации

●  Нерабочий код

Нужны ли беззнаковые целые?

Шестнадцатиричные и двоичные константы

Условные операторы

Переключатель

Циклы

●  Продолжение цикла и выход из него

Некошерный «goto»

Операции присвоения и проверки на равенство. Возможно ли однаковое обозначение?

Так ли нужны операции «&&», «||» и «^^»?

Постфиксные инкремент и декремент

Почему в PHP для конкатенации строк используется «.»?

Указатели и ссылки в C++

Использование памяти

Почему динамическое распределение памяти – это плохо

Как обеспечить возврат функциями объектов переменной длины?

●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●  Массивы переменной длины в C/C++

●  Размещение объектов в стеке, традиционный подход

●  Размещение объектов переменной длины с использованием множества стеков

●  Размещение объектов переменной длины с использованием двух стеков

●  Реализация двухстековой модели размещения данных

●  Двухстековая модель: тесты на скорость

●  Размещение объектов переменной длины с использованием одного стека

Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

Безопасность и размещение объектов переменной длины в стеке

Массивы, структуры, типы, классы переменной длины

О хранении данных в стеке, вместо заключения

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Прочее

Последние комментарии

2018/07/03 03:27, rst256
Философия языка

2018/06/25 15:10, Автор сайта
Продолжение цикла и выход из него

2018/06/14 00:37, rst256
Лень — двигатель прогресса

2018/05/31 18:52, rst256
Программирование без программистов — это медицина без врачей

2018/05/31 17:57, rst256
Циклы

2018/05/31 17:50, Comdiv
Разбор цепочек знаков операций

2018/05/31 17:42, Comdiv
Как отличить унарный минус от бинарного

2018/05/30 18:57, Александр Коновалов aka Маздайщик
Раскрутка компилятора