1

Тема: Национальный синтаксис Кантора

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

  • Условно принято, что локализация синтаксиса никак не обозначается во входном языке, а определяется автоматически, по ключевым словам.

  • Если потребность в локализации окажется высокой и потребуется различать близкородственные (германские, романские, славянские) языки, использующие одинаковый алфавит, определение синтаксиса сможет учитывать умолчание локализации данных -- строк и прочего, механизм которой будет штатно присутствовать в Канторе вне зависимости от локализации синтаксиса.

  • В основу процедуры локализации положены принципы консорциума Unicode:

    • Локализация разрабатывается носителями языка -- инициативными группами или энтузиастами.

    • Учитывается строй языка, присущие ему методы словообразования и семантики -- то есть переводятся не ключевые слова, а семантические конструкции целиком.

    • Наличие или отсутствие тех или иных языковых средств в естественном языке не является препятствием к их использованию в Канторе вообще.

  • Локализация идентификаторов библиотек может делаться двумя способами:

    • Факультативно -- путем описания библиотек-синонимов с идентификаторами на соответствующем языке. Способ основан на штатных возможностях Кантора: возможности использовать любые символы Unicode в идентификаторах, отсутствия накладных расходов на разрешение синонимов, удобного описания перегруженных синонимов оператором частичного применения -- partial. Этот способ подходит для частичной локализации группами энтузиастов на ранних этапах или малой востребованности локализации.

    • Системно -- изменением реализации обратимого кода, то есть добавлением измерения по языку. Реализация этого способа имеет смысл при наличии общественно значимых групп локализации, готовых работать на системной основе и имеющих для этого соответствующие ресурсы. С технической стороны потребуется проработка поведения среды при неполной локализации.

Факультативный способ локализации близок к тому, что имеется в современных версиях Delphi и C++ -- допустимость идентификаторов не только на латинице при неизменности системных библиотек.

Системный способ локализации будет похож на Алгол или локализацию встроенных функций Excel.

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

Добавлено 03.07.2015 в 11:48

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

Добавлено 05.07.2015 в 20:07

В настоящий момент в Канторе принято, что с заглавной буквы начинаются публичные имена, со строчной -- защищенные и локальные. Это обозначено в основах синтаксиса Кантора, в разделе "Рекомендуемые правила именования".

2

Re: Национальный синтаксис Кантора

Принято окончательное решение по альфе Кантора с русским синтаксисом -- в ней не будет ключевого слова класс.

3 (изменено: utkin295, 02.03.2016 в 21:20)

Re: Национальный синтаксис Кантора

Интересная тема, занимался подобными вопросами. Могу подкинуть идею как это видел я:
1. Как верно подмечено рассматриваются конструкции, а не отдельные слова. Это основа, причем это должна быть не основа локализации, а основа построения самого языка. Я рассматривал строки и работал с конструкциями, а не учебными примерами типа слова, токены, лексемы и т.д.
2. Следует из п.1 В самом языке программирования изначально должен отсутствовать высокоуровневый синтаксис. Я делал так - каждая конструкция (именно конструкция, а не конкретное слово или там токен) имел свой идентификатор, просто число от 0 и т.д. В общем виде конструкция имела следующий вид:
- идентфикатор;
- параметр1;
- параметр2;
- параметр3;
- параметр4.
Помимо прочего это позволяет очень быстро вносить новые вещи, например встроенные функции. После того как был создан каркас, я встраивал новые возможности по нескольку на день, пока был запал и горел интерес.
3. Параметры рассматриваются в контексте конструкции и в подавляющем большинстве случаев 4 параметра более чем достаточно (но вообще это никак не ограничено, можно добавить столько сколько нужно).
4. Синтаксис всегда хранится отдельно от семантики (у меня во внешнем файле). По началу я использовал разные файлы, для команд/операторов языка один и для встроенных функций/процедур другой. Но во время экспериментов и работы понял, что достаточно одного. Например, XML вполне годится для описания работы.
5. Я не учитывал регистр. Регистр это пережиток прошлого и наследие С. В современном мире это не имеет значения. И я бы на Вашем месте отказался от этой порочной практики, но решать разумеется Вам.
6. Я ввел такое понятие как множественность конструкций. Она позволяла приближать язык к естественному описанию.
Например,
Если параметр1 то параметр2
Если параметр1 тогда параметр2
При описании конструкции использовался один шаблон типа Если параметр1 то|тогда параметр2
Не знаю нужна ли Вам это идея, но так на заметку.
7. Я дополнительно писал утилитку, которая не только позволяла самому создавать свои синтаксисы, но еще и генерировала их описание в форме, приближенной к БНФ.
Некоторые более подробные описания изложены в журнале ПРОграммист (я там немного печатался).

4

Re: Национальный синтаксис Кантора

utkin295 пишет:

Регистр это пережиток прошлого и наследие С.

Регистр есть в математике, физике и естественном языке. Если стремиться к естественному языку, нужно быть последовательным.

5

Re: Национальный синтаксис Кантора

Проблема в неоднозначности правил. Где-то он обязателен, где-то нет. Поэтому я поступил аналогично - регистр есть вообще. Но как его использовать решает сам юзер. Система не накладывает никаких ограничений и не устанавливает правила. Это естественно и логично.

6

Re: Национальный синтаксис Кантора

utkin295 пишет:

Система не накладывает никаких ограничений и не устанавливает правила. Это естественно и логично.

как хачу так и пешу. Принято!

7

Re: Национальный синтаксис Кантора

Как только кто-то сделал что-то регистрозависимое и это что-то стало популярным, то остальные вынуждены следовать стандарту де-факто. Не зависимо от того, хорошо это или плохо, не беря во внимание ваши желания. Кто-то придумал беззнаковые целые - казалось бы, зачем? Ведь числа без знака можно легко выразить через числа со знаком. Если не хватает одного-единственного разряда - перейди на тип с удвоенной разрядностью. Но нет... И теперь все вынуждены поддерживать числа без знака. В WinAPI есть и регистрозависимость, и беззнаковые целые. Но поздно пить "Боржоми", теперь надо придерживаться генеральной линии.

8

Re: Национальный синтаксис Кантора

Юрий пишет:

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

А вот на своем форуме вы когда-то писали, что Кантор демонстрирует независимость мышления. wink

В Канторе нет встроенных типов, а в корневом пространстве имен могут быть только ключевые пространства, имеющие особый смысл (Core, System и пр.), из-за чего полные имена классов и свойств -- длинные "паровозики". В этих условиях возникает естественное желание сами идентификаторы делать как можно короче и без префиксов. Сравните, например:

Core:Typecast:Integer
NSCore:NSTypecast:TInteger
nsCore:nsTypecast:tInteger

Аналогично и для свойств классов:

Control.Size.X
TControl.PSize.PX
tControl.pSize.pX

А теперь представьте, что вам нужно описать связанные по смыслу публичные и защищенные свойства с одинаковым набором параметров. Как их назвать? Это естественная сложность фрактальной модели, никуда от нее не деться.

Одновременно с ней есть кантование -- основанный на перегрузке способ объявления свойств, подразумевающий одинаковость имен и различие по параметрам. (К сожалению, лекция по кантованию не состоялась, а в форумной теме я не могу быстро объяснить подробнее).

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

public class Size of
  var Core:Integer width, height;
  public Width = width;
  public Height = height;
end;

Объявления публичных свойств читаются вполне математически:

  • публичное "Width" равно "width малое";

  • публичное "Height" равно "height малое";

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

Опыт Си и Оберона

Принимая решение о регистре, я учитывал опыт двух известных мне языков, рассматривая опыт Си как положительный, а опыт Оберона -- как отрицательный. В Обероне нет математичности Си, зато вместе с чувствительностью к регистру ключевые слова пишутся заглавными буквами, из-за чего текст выглядит непривычно для программиста на Паскале/Delphi, привыкшего к оформлению Borland...

Глобальными пространствами Кантор похож на C# и Java, а в них регистр не доставляет какого-либо неудобства. Получилось у Гослинга с Хейлсбергом -- получится и у меня.

Беззнаковые целые — вне темы национального синтаксиса
Юрий пишет:

Если не хватает одного-единственного разряда - перейди на тип с удвоенной разрядностью. Но нет... И теперь все вынуждены поддерживать числа без знака.

WinAPI и Кантор ориентированы на системное программирование. Раз беззнаковые целые есть в процессоре — будут и в языке. Сделайте свой процессор только со знаковыми регистрами, и на вашей архитектуре беззнаковое целое будет ограниченным типом — подмножеством знакового.

9 (изменено: Freeman, 07.05.2016 в 19:01)

Re: Национальный синтаксис Кантора

На Хабре началась эпидемия русских синтаксисов JavaScript:

Имеем ли мы дело с новым явлением в Рунете, пока трудно сказать. Наблюдаем...

Кстати, в одном из комментариев поднята актуальная тема -- отсутствие части математических символов в русской раскладке. Мне кажется, что при разработке русского синтаксиса это обязательно надо учитывать. Так поступили разработчики WackoWiki: они специально изменили синтаксис вики-разметки, чтобы ею можно было пользоваться без переключения раскладки. Именно поэтому встроенная в Кантор вики основана на диалекте WackoWiki.

Сходу предложить замену знакам < и > не могу. Нужно исходить из того, что миллионы выпущенных клавиатур мы не изменим, придется искать обходные пути. Сами собой напрашиваются сокращения, вроде мнш/мнр и блш/блр:

вернуть если дискриминант блш 0 то
  'Два корня'
иначе дискриминант = 0 то
  'Один корень'
иначе
  'Корни мнимые'
конец;

Мнемоники вместо знаков сравнения присутствуют в ассемблерах и в командном языке bat-файлов Windows, где символы < и > обозначают перенаправление ввода-вывода.

Кому-то на форуме такое решение наверняка не понравится. Что еще тут можно предложить? Предлагайте.

10

Re: Национальный синтаксис Кантора

Дожили. Такой код нужно снабжать английскими комментариями, раз на то пошло