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

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

Прежде, чем рассуждать, в каком стиле должен быть выдержан синтаксис идеального языка программирования, давайте почитаем, что об этом говорили до нас. Привожу выжимку из раздела «Синтаксический сахар» из книги Джека Креншоу «Давайте создадим компилятор!».

            Синтаксический сахар — это такие конструкции языка программирования, которые совершенно не нужны компилятору. Синтаксический сахар нужен программисту для чтения и понимания программ. Примеры синтаксического сахара: точка с запятой; «THEN» после «IF»; «DO» перед «WHILE». Эти элементы синтаксиса «утяжеляют» язык и компилятор. Но часто делают программы более понятными.
            Существует две школы в этом вопросе: Си и Паскаль.
            Сторонники Си-шного подхода считают, что синтаксический сахар должен быть выброшен. Язык и компилятор от этого станут компактнее. Программисты будут делать меньше нажатий на клавиши. Каждая дополнительная конструкция — капкан, который ждёт «своего клиента». Лучший способ избежать таких ловушек — исключить их из языка вообще.
            Оппоненты из лагеря Паскаля считают, что набор нескольких дополнительных символов — малая цена за удобочитаемость. Люди тоже имеют право читать программы. Сахарные токены — полезный ориентир, чтобы не сбиться с пути. Ошибочная конструкция на Си часто не является формально ошибочной, она вполне допустима синтаксическими правилами. Их аргумент в том, что каждая такая конструкция является возможностью сообщить компилятору, что вы действительно хотите того, что сказали.

            Лучший пример полезного сахара — точка с запятой. Вот код:
            a=1+(2*b+c) b
компилятор поймёт, что b — начало нового утверждения. На самом деле хотели написать:
            a=1+(2*b+c)*b
Если после и будет точка с запятой, то нет сомнений, где заканчивается утверждение. Здесь синтаксический сахар — дополнительная подстраховка.
            Я нахожусь где-то посередине между этими подходами. Я склоняюсь к преимуществам Паскалевской точки зрения, чтобы находить ошибки во время компиляции, а не во время выполнения. Но я ненавижу просто бросаться словами без явной причины, как в COBOL. Я могу позволить синтаксическому сахару существовать в небольшом количестве.

Не увлекайтесь сахаром.
            Для начала хотелось бы возразить Джеку Креншоу, что точка с запятой тоже может играть деструктивную роль. Например:
	if (a > b);
	    a = 0;
или
	for (i=0; i<100; i++);
	    function();
            В приведённых примерах точка с запятой после «if» и «for» была поставлена по ошибке. Но синтаксис языка допускает это, обрывая в первом случае условное выражение, а во втором — цикл. В результате мы имеем код, в котором точка с запятой «спряталась», и надо приложить усилия, чтобы её обнаружить. В этом случае было бы полезнее иметь в качестве разделителя лексем «перевод строки»: его не заметить невозможно!

             Второе возражение. Цитирую:

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

Что на самом деле было сказано компилятору, выясняется только во время всестороннего анализа и тестирования программы. Нередко фразу «я сказал компилятору» после такой проверки следует заменять на «я думал, что я сказал компилятору вот это, а на самом деле сказал другое».

             Теперь вернёмся к теме разговора.

Cинтаксический сахар заменяем графическим

             Программисты XXI века не могут почувствовать на своей шкуре, что такое вводить код программы в память компьютера с помощью тумблеров и кнопок. Или набивать его на перфокарты, нумеруя их карандашом. Без этой нумерации потом трудно найти нужную перфокарту для замены ошибочного кода. До появления дисплеев программисты видели свой код только на бумаге. Поэтому синтаксический сахар был одним из средств улучшения восприятия программы. Но нужен ли он в эпоху GUI ?

             Давно сложившиеся стереотипы говорят нам, что если программист нуждается в синтаксическом сахаре, то он сам своими руками должен долбить этот сахар на клавиатуре. Классики классифицировали эту проблему как «спасение утопающих». Но почему бы эту задачу не переложить на компьютер? Ведь он трудолюбивее программиста.

             Компиляторы и редакторы текста программ давно интегрированы в IDE. Пусть IDE этим и занимается. Нет, IDE не должна самостоятельно вставлять «THEN» между «IF» и «ELSE». Пусть текст программы останется неизменным. Программист должен видеть на экране свою программу, которую IDE в значительной степени преобразила, дополнила графическими элементами.

             При этом разделение труда таково. Программист вводит текст программы. Этот текст максимальным образом лишён всех синтаксических излишеств. А вот IDE по мере ввода программистом программы, анализирует его и дополняет графикой! Для программиста синтаксический сахар возникает сам по себе. Он не прикладывает для этого дополнительных усилий. Каков должен быть сахар — решает сам программист, меняя настройки IDE. Нужно сопровождать элементы конструкций графикой — программист выставляет соответствующие настройки IDE. Для каждого типа графических элементов.

Синтаксический сахар или синтаксический мусор? Или лексический мусор?

Наводим порядок в терминологии. Само понятие «синтаксический сахар» не имеет научного определения, оно сложилось стихийно. Существует две трактовки этого понятия:
  • доминирующая: это возможность записать одинаковые по сути конструкции разными способами;
  • трактовка Креншоу, имеющая место быть при проектировании нового языка программирования, когда некоторые конструкции этого языка вводятся лишь для «наглядности».
Во втором случае синтаксический сахар было бы правильнее назвать синтаксическим мусором. А если учесть, что «лишние слова» в языке программирования — это лишние лексемы, то ещё правильнее назвать это лексическим мусором.

Что ещё почитать на эту тему

Последняя правка: 2018-10-29    16:03

ОценитеОценки посетителей
   ████████████████████████ 20 (57.1%)
   ██████████████ 11 (31.4%)
   ███ 2 (5.71%)
   ███ 2 (5.71%)

Отзывы

     2013/04/18 20:13, Михаил

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

     2013/04/19 13:45, Автор сайта

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

Возьмём его цитату: «Самым лучшим примером полезного сахара является непосредственно точка с запятой». В узком смысле точка с запятой не является синтаксическим сахаром: без неё невозможно обойтись ни в Си, ни в Паскале, написав как-то по-другому. В широком же понимании этого термина без точки запятой обойтись можно, как обходятся, к примеру, в Ruby или Nemerle

Да, Вы правы, когда говорите о синтаксическом сахаре в уже существующих языках. В процессе же проектирования нового языка «лишние» конструкции, наверное, всё-таки можно назвать «синтаксическим сахаром». А Вы бы как их назвали?

     2013/04/23 14:25, Михаил

Я бы назвал их неудачным решением при проектировании грамматики языка. Всё-таки называть синтаксическим сахаром то, без чего существующая грамматика языка развалится не вполне верно. Например, из Си можно полностью и безболезненно удалить цикл for, семантика языка не пострадает.

     2013/04/25 11:07, Автор сайта

Когда язык программирования делается с чистого листа, то как бы Вы назвали то, без чего в языке можно обойтись? Когда компилятору элемент синтаксиса не нужен, но некоторые программисты находят его улучшающими читаемость? В Википедии пишут: «понятие синтаксического сахара во многом условно». Там же есть ссылка на Креншоу; я употребляю это понятие в том же смысле, что и он.

«Другой же способ записи для уже имеющихся синтаксический конструкций» часто использует другую семантику, поэтому это уместнее назвать «семантическим сахаром». Если цикл заменяется рекурсией — это совсем иная семантика, не правда ли? А синтаксис — этот лишь способ записи определённой семантики, изыски оформления. Присутствие «then» в операторе «if» совсем необязательно, это лишь «украшение». Можно составить грамматику языка так, чтобы без него обойтись. Конечно, если вести речь о уже готовых языках, то обойтись без «then» уже нельзя, если он «зашит» в грамматику, а грамматика — в компилятор.

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

     2016/08/10 20:23, rst256

Присутствие «then» в операторе «if» совсем необязательно, это лишь «украшение».

Я с вами полностью согласен, так почему же вы с собой не согласны:

2016/06/03 12:14, автор: Автор сайта
Конец строки (точнее — «конец выражения») после условия должен быть обязательно. А конец строки — это либо 16"0d0a", либо точка с запятой. Приведённый пример можно оформить и так:
x = (if x==y; -a; else -b)

Вы же прекрасно понимаете что "then" просто лексический сепаратор, не важно, что вы задействуете в его качестве. Для языков, чей синтаксис не позволяет без сепаратора точно определять конец выражения "then" и ";" необходимы компилятору не меньше чем Си-строке нультерминирующий символ. Я приводил пример языка Lua, где реализовано "мягкое отсечение" для выражений. Вы согласны, что "then" и ";" надо убрать, значит надо убрать:

1. "x = (if x==y; -a; else -b)" — условный оператор внутри выражения должен быть как в си, а для трех и более этажных выражений более подойдет конструкция аналогичная сишной "({ ...; ...; ... })"

2. "-a=...; *a=...;" и все иные унарные операции, совпадающие с бинарными в начале нового предложения, быть не должно. Можно сделать "--" и "++" в этой части постфиксными, ну а разадресация у вас уже и так не конфликтует.

В синтаксисе, который описан на данный момент, других препятствий более нету.

     2016/08/19 03:26, rst256

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

     2016/08/20 06:27, rst256

Как вам язык ВООБЩЕ с разделителями только когда это необходимо?
void foo(...){...}
...
foo(i2)
foo(i2 55 6+7 bar(...)+2) // => foo(i2, 55, 6+7, bar(...)+2)
foo(i2, -i3 6+7) // => foo(i2, -i3, 6+7)
/* а кому не нравится могут ставить их всегда */
foo(i2, 55, 6+7l, bar(...)+2);
foo(i2, -i3, 6+7);
Так делается в языке Lua где нет разделителей между отдельными командами, однако допустимо их явное указание. На нем код "а1=55+1 а2=а1+3" эквивалентен коду "а1=55+1; а2=а1+3;", и оба этих варианта допустимы в языке.

Правда, разделители между аргументами функций "," там все же есть. Но почему бы не пойти дальше?

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

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

Авторизация

Регистрация

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

Карта сайта


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии

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

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

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

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

●  Помеченные комментарии

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

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

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

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

Циклы

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

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

Изменение приоритетов операций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●  Изменение длины объекта в стеке во время исполнения

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

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

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

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

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

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

Компилятор

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

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

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

Прочее

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

2018/12/08 23:03 ••• Попов Михаил
✎ Программирование без программистов — это медицина без врачей

2018/12/07 08:57 ••• Автор сайта
✎ Почему обречён язык Форт

2018/12/07 08:36 ••• Автор сайта
✎ Нужны ли беззнаковые целые?

2018/12/03 13:51 ••• kt
✎ Экстракоды при синтезе программ

2018/11/30 17:56 ••• Freeman
✎ Изменение приоритетов операций

2018/11/30 17:20 ••• Автор сайта
✎ Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2018/11/26 14:23 ••• Автор сайта
✎ Так ли нужны операции «&&», «||» и «^^»?

2018/11/18 15:21 ••• Freeman
✎ Устарел ли текст как форма представления программы

2018/11/17 03:28 ••• Comdiv
✎ Изменение длины объекта в стеке во время исполнения

2018/11/16 12:53 ••• Автор сайта
✎ Помеченные комментарии

2018/11/11 14:01 ••• Александр Коновалов aka Маздайщик
✎ Нерабочий код

2018/11/11 13:39 ••• Александр Коновалов aka Маздайщик
✎ О русском языке в программировании