Строгое определение синтаксического сахара? [закрыто]

Похоже, что в священных языковых войнах люди постоянно унижают любую особенность, которую они не находят особенно полезной, как «просто синтаксический сахар». Граница между «реальными особенностями» и «синтаксическим сахаром» имеет тенденцию размываться в этих дебатах. Что, по вашему мнению, является разумным и однозначным определением синтаксического сахара, которое позволяет избежать его определения в качестве любой функции, которую оратор / писатель не находит полезной?

Как насчет этого: «синтаксический сахар - это удобное сокращение для некоторой функциональности, которая не вводит какой-либо значимый уровень абстракции».

Бери a->b, что, как ты отмечаешь, эквивалентно (*a).b. Позволяет ли эта нотация рассматривать код в каком-либо полезном, иначе скрытом виде? Нет, так что это синтаксический сахар.

Теперь посмотрим a[i] == *(a + i). Подумайте о любой программе на C, которая использует массивы любым существенным образом. Можете ли вы представить себе попытку понять это без []обозначений? С многомерными массивами? Целесообразно рассматривать массивы как единые целые, а не как ссылку на начало непрерывного блока памяти. Хотя полезно знать, как работают массивы в C, если вы планируете делать с ними сложные вещи, непродуктивно всегда думать: «Мне нужно хранить два бита памяти в 2 * i байта справа от место в памяти, на которое ссылается a". Весь смысл массива заключается в способности абстрагироваться от процесса сохранения последовательности как связной единицы. []Обозначения облегчает эту абстракцию. Это не синтаксический сахар.

Это не значит, что синтаксический сахар - это всегда плохо. Как и многие аллитерации, он стал эпитетом и противопоставлен «реальным чертам». Но LISP и Схема, например, были бы нечитаемыми, если бы не letстенография (и другие).

Тройной оператор <pred> ? <cnsq> : <alt>, является еще одним примером. Синтаксический сахар может помочь в организации программ и удалении избыточного кода, что может сэкономить на обслуживании в дальнейшем. Синтаксический сахар иногда может быть предпочтительнее, чем нагромождение «реальных функций», если это помогает устранить синтаксические барьеры в программировании.

Цитируя R ^ 5RS : «Языки программирования должны разрабатываться не путем добавления элементов поверх функций, а путем устранения недостатков и ограничений, которые делают дополнительные функции необходимыми». ИМХО, синтаксис может квалифицироваться как слабость и ограничение, и поэтому позволить программистам уйти от синтаксиса может повысить выразительность языка.

ИМХО, я не думаю, что у вас может быть определение для синтаксического сахара, потому что эта фраза написана на BS и, вероятно, будет использоваться людьми, которые говорят о «настоящих программистах», использующих «настоящие инструменты» в «реальных операционных системах»

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

Его BS, потому что некоторые утверждают, что следует избегать использования сахара, потому что вы можете написать ошибку, но вы должны придерживаться ее, потому что она труднее писать ошибки. Разве это не круто? Одна и та же фраза приводит к совершенно противоположным выводам с использованием одной и той же логики.

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

Это BS, потому что люди часто ошибаются или ошибаются в отношении эквивалентности. Например, этот вопрос утверждает, что строка C # является сахаром для массива char. Это не так .

Однако, если вы хотите сказать, что две вещи являются сахаром, если они семантически эквивалентны, и это помогает идти вперед и определять его так, как вы хотите.

Если вы хотите быть пренебрежительным по отношению к кому-либо, вы также можете использовать эту фразу.

Вот очень строгое определение родственного понятия: выразительность ,
Матиас Феллайзен:

О выразительной силе языков программирования [Постскриптум был единственной свободной формой, которую я смог найти.]

Также смотрите эту запись о языке Java и замыканиях .

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

Тем не менее, синтаксический сахар хорошо при правильном использовании. Я думаю, что любой программист на Scheme предпочел бы letспециальную форму, чем создавать новую анонимную функцию, а затем применять ее, что делало бы то же самое. Цель состоит в том, чтобы сделать код более понятным.

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

Возьмем, например, язык программирования A, в котором есть операция, sumкоторая может составлять список целых чисел произвольной длины. На этом языке мы можем написать выражения

sum []
sum [3, 4, 5, 1]
sum [2, 7]

результаты которого 0, 13 и 9 соответственно.

Теперь предположим, что мы понимаем, что 90% случаев мы используем sumс двумя аргументами, и поэтому мы вводим, для удобства, новые обозначения

2 + 7

который является просто синтаксическим сахаром для sum [2, 7].

Теперь возьмите второй язык B, который не имеет никакой операции добавления. У нас могут быть такие операторы, как <, =что позволяет нам сравнивать числа, но нет возможности добавлять числа. В выпуске 2 языка B мы вводим новую операцию добавления с синтаксисом

2 + 7

который добавляет цифры как обычно.

В контексте языка A +нотация является синтаксическим сахаром (это альтернативная, упрощенная и специальная нотация, которую можно использовать вместо sum [...]нотации). Точно так же, как указывалось в ответе Хоа Лонг Тэма, в С нотация p->fieldявляется синтаксическим сахаром для (*p).field.

В контексте языка B +нотация не является синтаксическим сахаром (это единственный допустимый синтаксис, используемый для операции суммирования). Точно так же, если бы C мог получить доступ к элементам структуры только через указатели и если бы не имел нотации (*p).field, то нотация p->fieldне была бы синтаксическим сахаром.

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

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

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

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

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

Я сделал это описание немного длинным, но я думаю, что это важный аспект, который я не видел в других ответах.

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

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

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

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

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

Пример вещей, которые являются синтаксическим сахаром:

a[i] вместо *(a + i)

a -> b вместо (*a).b

foreach синтаксис вместо того, чтобы вручную вводить синтаксис итератора.

Вся перегрузка оператора - чистый синтаксический сахар.

Похоже ли это на справедливое и достаточно однозначное определение?

«Синтаксический сахар» не является строго определенным термином. В зависимости от того, кого вы спросите, вы, скорее всего, получите одно из следующих определений:

1. Нет настоящего шотландского подхода. Вещи, которые мне нравятся, - это настоящее программирование, а вещи, которые мне не нравятся, - синтаксический сахар.
2. Все после MIPS было синтаксическим сахаром, и даже некоторые из этих инструкций, вероятно, не нужны.
3. Все, что облегчает программирование для кого-то где-то, полезно и не является синтаксическим сахаром. Поскольку функция не была бы добавлена, если бы никто не нашел ее полезной ни при каких обстоятельствах, из этого следует, что каждая существующая функция не является синтаксическим сахаром. Гипотетические особенности могут быть синтаксическим сахаром, пока кто-то не решит, что функция полезна для них.

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

Применив соответствие Карри-Ховарда, можно придумать параллельное понятие о «синтаксическом сахаре».