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

Правила языка: строки, комментарии

Строки и операторы

Символ перевода строки 

	=  ��  (шестнадцатиричное 0D0A)
	|  �  (шестнадцатиричное 0A)
	|  �  (шестнадцатиричное 0D)

Исторически сложилось так, что перевод строки на разных платформах реализован по-разному. Это правило учитывает все варианты.

Символы перевода строки (шестнадцатиричное 0D, 0A) «поглощаются» внутри лексем продолжение строки, длинный комментарий и документирующий комментарий. Эти символы, конечно, остаются, но в составе этих лексем. В этом случае влияют только на номер строки в тексте программы (для отображения в тектовом редакторе или в сообщениях об ошибке), но не являются концом оператора.

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

Символы перевода строки (шестнадцатиричное 0D, 0A) «поглощаются» внутри лексем продолжение строки, длинный комментарий и документирующий комментарий. Эти символы, конечно, остаются, но в составе этих лексем. В этом случае влияют только на номер строки в тексте программы, но не являются концом оператора.

Перевод строки = 

	{ Символ перевода строки }¹

Если перевод строки встречаются несколько подряд, то не играет роли, сколько раз он встретился.

Последовательность пустых символов = 

	{ Пустой символ }¹

Продолжение строки = 

    =  ...  [ Последовательность пустых символов ] Перевод строки

    | Контекстная зависимость 

    [Последовательность пустых символов] Перевод строки

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

 z = f (x,
        y)
 A = B +
     C
 Структура .
   член структуры =
      нечто

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

  (*  {  *  } {  любые символы  }
	{ Контекстная зависимость  *  }  *) 
 Количество звёздочек в конце комментария 
 должно быть не меньше, чем в начале

Этот вид комментария аналогичен комментарию вида /* { любые символы } */, знакомому по другим языкам программирования. Отличается в лучшую сторону тем, что решает проблему вложенности комментариев. Комментарии вида (* ... *) всегда можно вложить внутрь других, увеличив количество звёздочек:

    (*** Комментарии с тремя звёздочками могут включать в себя
	комментарии с двумя звёздочками и одной
	(** Комментарии с двумя звёздочками могут включать в себя 
	       комментарии с одной звёздочкой
	    (* Комментарий с одной звёздочкой
	    *)
	**)
    ***)

А вот обратное неверно: комментарий с меньшим числом звёздочек не может включать в себя комментарий с большим количеством звёздочек. Так же следует учитывать, что комментарии

    (* ... ****)

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

Выгода замены /* ... */ на (* ... *) в том, что последний вариант «отключает» при надобности блоки внутри скобок, просто добавив звёздочки:

    // было:
	( некий блок )
    // теперь отключаем:
	(* некий блок *)

Документирующий комментарий

    =  <html>  {любые символы}  </html> 

    |  <ягтр>  {любые символы}  </ягтр> 

    |  [wiki]  {любые символы}  [/wiki] 

    |  [вики]  {любые символы}  [/вики]

С назначением этого этого вида комментария можно познакомиться в статье Комментарии автоматической генерации документации.

P.S. Этот вариант синтаксиса пока что является черновым.

Пустой оператор

    = Последовательность пустых символов

    | Продолжение строки

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

    | Документирующий комментарий }

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

Пустой оператор настолько пустой, что может встречаться внутри идентификаторов, между идущими рядом ключевыми словами, внутри числовых констант. Исключением являются строковые константы, внутри которых пустой оператор превращается в обычный текст.

Примеры:

  Идентификатор состоящий из нескольких ...
  слов			// Это всё идентификатор
  Это тоже (* комментарий внутри *) идентификатор
  123 (* миллиона *) 456 (* тысяч *) 7 8 9
  1 6: FE DC BA 98

Приведённое выше на Си записали бы так:

  ИдентификаторСостоящийИзНесколькихСлов
  ЭтоТожеИдентификатор
  123456789
  0xFEDCBA98

Точка с запятой

    =  ;

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

    =  //  {  любые символы  } Перевод строки

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

Конец оператора

    = { Перевод строки

    | Точка с запятой

    | Короткий комментарий }¹

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

Перевод строки и точка с запятой, как правило, взаимозаменяемы и равнозначны в синтаксисе и семантике. Исключением является продолжение строки и короткий комментарий, которые обязательно заканчиваются переводом строки, но никак не точкой с запятой.

 // Можно так
 z = f (x, y)
 A = B + C
 // а можно эдак
 z = f (x, y); A = B + C

Опубликовано: 2023.05.02, последняя правка: 2023.05.02 23:40

Оцените	Оценки посетителей
Нравится	█████████████████ 5 (38.4%)
Неплохо	███████ 2 (15.3%)
Так себе	█████████████ 4 (30.7%)
Не нравится	███████ 2 (15.3%)

Отзывы

✅ 2024/11/06 00:35, Борис К. #0

Вот всегда меня настораживал строчный комментарий. И вообще использование перевода строки в качестве полноценной лексемы.

 // Как же так. Нельзя же так.
 z = f (x,
	y)

✅ 2024/11/09 00:05, Автор сайта #1

Не нравятся однострочные (короткие) комментарии — пишите многострочные (длинные) комментарии. Мне кажется, комментарии — не самое тяжёлое в программировании. Трудности преодолимы.

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

✅ 2024/11/09 08:50, Клихальт #2

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

Миллиарды мух не могут ошибаться?

✅ 2024/11/09 14:37, Неслучайный читатель #3

Синтаксическому дереву всё равно, каким способом заканчивается конструкция языка. Хоть точкой с запятой, как в алголоподобных языках, хоть концом строки, как в ассемблерах, Питоне или Хаскелле. А вот миллиарду мух не всё равно. При программировании они могут совершать ошибки. Чтобы их было меньше, надо выбрать удобный способ программировать. Половине от этого миллиарда для удобства нужна точка с запятой, а другой половине она мешает. Вот так и живём, не отделяя мух от коктейлей.

✅ 2024/11/10 15:01, Борис К. #4

Предлагаемое продолжение строки приводит к неоднозначности вида

x = f(a) = y
x = f
     (a) = y

✅ 2024/11/10 23:46, Автор сайта #5

x = f
     (a) = y

Явно не вписываются в правила. После f наступает конец строки. Значит f — обычная переменная, которая не объявлена и не инициализирована. Значит, присвоение в первой строке компилятор квалифицирует как ошибку. Во второй строке a, которая в скобках, тоже не объявлена и не инициализирована.

✅ 2024/11/11 10:19, Борис К. #6

Имелась в виду сишная жесть в выражениях. С неожиданным смыслом дурных опечаток. А уж если сюда и перенос строки добавить...

void *u,*w,*a,*x,*y;
void*& f(void* v){ return v==nullptr?u:w; }

x = f
     (a) = y;

x = f;
     (a) = y;

✅ 2024/11/12 00:47, Автор сайта #7

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

✅ 2024/11/12 08:16, Вежливый Лис #8

Это правило учитывает все варианты.

Но записано оно плохо. Понятно, но неудачно. Кроме того, мне кажется, что в правиле пропало имя нетерминала, потому что оно было в угловых скобках, а HTML их съел.

перевод_строки
        : аскии_код_перевода_строки
        | аскии_код_возврата_каретки необязательный_хвост
    
необязательный_хвост
        : ε
        | аскии_код_перевода_строки

аскии_код_перевода_строки
        : '0x0A' // Эскейп-последовательнсть для Си = '\n'
    
аскии_код_возврата_каретки
        : '0x0D' // Эскейп-последовательнсть для Си = '\r'

Такой вариант лучше тем, что является праволинейным (то есть лучше подходит для реализации на ДКА, в рекурсивном спуске и т.п.)

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

Что же мы делаем, когда размещаем строки текста вертикально? Мы ориентируемся на особенности строения именно людей, на двумерность поля зрения, закладываем её в модель текста. А были бы иноплянетяне с объёмным органом чувств — только переводами строк дело бы не ограничилось.
Если мы делаем последовательное наращивание сложности инструментов, то на каком этапе мы переходим от линейности мысли к двумерности программного кода? Это именно людям нужно, а не трансляторам, значит где-то между си и питоном (если сишный препроцессор проигнорировать в рассмотрении)?

Ещё мне не нравится слово "перевод". Синтаксис, описывающий язык, не должен вообще заморачиваться с аппаратными средствами и с кодировками тоже. Это не к языку относится, а к аппаратной платформе. Поэтому грамматики надо разделять на платформонезависимую (работающую с символами) и платформозависимую, описывающими как тот символ в виде кластера графем собирается из кодепоинтов с ударениями и умляутами. Поскольку транслятору ЯЗЫКА не важно знать, какая там у терминала (или это был принтер?) готовка, и как подавать под неё бумагу барабаном, то символ должен называться не "символ перевода строки", а "разделитель строк", "символ разделения строк" или как-то так. Только факт раздельности строк важен транслятору языка.А в языке разве уже нет похожего символа, который что-нибудь разделяет? Точка, к примеру, разделяет предложения. А предложение — это законченная мысль. Что же "не так" пошло в языках программирования, что понадобился другой (ещё один?) символ?

✅ 2024/11/12 14:28, Автор сайта #9

Если мы делаем последовательное наращивание сложности инструментов, то на каком этапе мы переходим от линейности мысли к двухмерности программного кода?

Линейным бывает разбор, для него текст одномерный. А человеческое зрение двухмерное. Для инструментов переход к двухмерности увеличивает сложность, а для человека — не особо.

символ должен называться не "символ перевода строки", а "разделитель строк", "символ разделения строк" или как-то так. Только факт раздельности строк важен транслятору языка.

Транслятору по барабану, как называется символ с кодом 10 или 13. Только факт равенства 10 или 13 важен. Все экзотичные кодировки уходят в прошлое, остаются только общепризнанные. Поэтому разговоры о платформозависимых или независимых кодировках становятся схоластикой. 10 и 13 — он и в Африке 10 и 13.

разве уже нет похожего символа, который что-нибудь разделяет? Точка, к примеру, разделяет предложения. Что же "не так" пошло в языках программирования, что понадобился другой (ещё один?) символ?

Всё пошло не так, когда извращенцы стали использовать точку нетрадиционно, типа того: человек.фамилия, человек.имя, object.property, fox.tail и т. д. Вот тогда точку в конце предложения и заменили на точку с запятой. Но потом возобладала идея заменить точку с запятой на то, что многие и символом не считают. Потому что его не видно. Это те самые «\n» и «\r». И ведь неплохо получилось. Символа не видно, но строка в этом месте заканчивается и надо переходить к следующей.

✅ 2024/11/12 16:33, Вежливый Лис #10

Линейным бывает разбор, для него текст одномерный.

То есть, происходит двойное преобразование: сначала линейная мысль преобразовывается в плоский текст, а затем плоский текст преобразовывается в линейный входной язык транслятора.

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

А вот у процессора с внешними устройствами наоборот, от параллельных интерфейсов избавляются, используют последовательные (SATA, например вместо PATA). Противоречие. Надо выяснить, в чём же дело.

✅ 2024/11/12 18:28, Автор сайта #11

линейная мысль

Мысль — это просто мысль. Её аршином общим не измерить. Какая она — линейная или многомерная — никто не знает.

мысль преобразовывается в плоский текст

Преобразуется? В природе не существует таких преобразователей. Человек не преобразователь, а родитель и носитель мысли. Хотя он пишет текст сообразно своим мыслям.

Противоречие. Надо выяснить, в чём же дело.

Не выясняйте. Разочаруетесь.

✅ 2024/11/12 20:24, Вежливый Лис #12

Имея более точную модель происходящего можно будет лучше использовать имеющиеся возможности. Возможно, даже, превзойти питон по использованию блочновертикальности.

Добавить свой отзыв

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

Содержание

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

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

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

● Философия языка

● Правила языка: алфавит