Схоже, що в мовних святих війнах люди постійно заперечують будь-яку особливість, яку вони не вважають особливо корисною, як "просто синтаксичний цукор". Межа між "реальними ознаками" та "синтаксичним цукром", як правило, розмивається в цих дебатах. Як ви вважаєте, що розумне та однозначне визначення синтаксичного цукру дозволяє уникнути його визначення як будь-якої функції, яку оратор / письменник не вважає корисною?
Відповіді:
Як щодо цього: "синтаксичний цукор - це зручність скорочення деяких функціональних можливостей, які не вносять жодного змістовного шару абстракції".
Візьміть a->b, що, як ви зазначаєте, рівнозначне (*a).b. Чи дозволяє це позначення розглянути код, який він корисний, інакше прихований? Ні, так це синтаксичний цукор.
Тепер розглянемо a[i] == *(a + i). Подумайте про будь-яку програму C, яка використовує масиви будь-яким змістовно. Ви можете уявити, як намагаєтесь зрозуміти це без []позначень? З багатовимірними масивами? Доцільно розглядати масиви як цілі одиниці, а не як посилання на початок суміжного блоку пам'яті. Хоча це допомагає знати, як працюють масиви в C, якщо ви плануєте робити з ними складні речі, непродуктивно завжди думати: "Мені потрібно зберігати два біти пам'яті 2 * я байтів праворуч від місце пам'яті, на яке посилається a. " Вся суть масиву - це можливість абстрагувати процес зберігання послідовності як цілісної одиниці. []Позначення полегшує цю абстракцію. Це не синтаксичний цукор.
Це не означає, що синтаксичний цукор - це завжди погано. Як і багато алітерацій, він став епітетом і насупроти "реальних рис". Але LISP та схема, наприклад, були б нечитатими, якби не letскорочення (та інші).
Потрійний оператор <pred> ? <cnsq> : <alt>, - ще один приклад. Синтаксичний цукор може допомогти організувати програми та видалити зайвий код, що може заощадити на технічному обслуговуванні. Синтаксичний цукор іноді може бути кращим, ніж накопичення "реальних особливостей", якщо це допомагає усунути синтаксичні бар'єри для програмування.
Цитуючи R ^ 5RS , "Мова програмування повинна бути розроблена не шляхом складання функції на верхній частині функції, а шляхом усунення слабких місць та обмежень, які роблять необхідними додаткові функції". IMHO, синтаксис може кваліфікуватися як слабкість і обмеження, тому відпущення програмістів від синтаксису може збільшити виразність мови.
IMHO Я не думаю, що ви можете визначити синтаксичний цукор, тому що ця фраза є BS і, ймовірно, буде використана людьми, які говорять про "справжніх програмістів", використовуючи "реальні інструменти" на "реальних операційних системах"
Його BS тому, що ідея "реальних рис" або "синтаксичного цукру" схожа на відсутність справжньої помилки шотландця . У тому, що фрази - це "спеціальні спроби зберегти необгрунтоване твердження". Твердження тут полягає в тому, що функція тут є тривіальною, тому що ви можете використовувати "реальну функцію" замість цього.
Його BS тому, що деякі заперечують використання цукру, слід уникати, тому що ви можете написати помилку, але слід дотримуватися цього, оскільки важче писати помилок. Хіба це не дивовижно. Ця ж фраза веде до прямо протилежних висновків, використовуючи ту саму логіку.
Його BS тому, що ніхто не цитує дослідження зручності використання або дослідження кількості дефектів, щоб підкріпити їх читабельність чи ремонтопридатність або ймовірні аргументи дефектів.
Його BS тому, що люди часто помиляються або помиляються щодо еквівалентності. Наприклад, це питання стверджує, що рядок C # - це цукор для масиву char. Вони ні .
Однак, якщо ви хочете сказати, дві речі - це цукор, якщо вони семантично еквівалентні, і це допомагає йти вперед та визначити його в будь-якому випадку, що вам потрібно.
Якщо ви хочете зневажити когось, ви також можете використати фразу.
Ось дуже суворе визначення спорідненого поняття: виразність ,
Маттіас Феллейзен:
Про виразну силу мов програмування [Postscript був єдиною вільною формою, яку я міг знайти.]
Також дивіться цей запис на мові Java та закритті .
Ефективно щось є синтаксичним цукром, якщо його можна змінити на форму без синтаксису, лише внісши локальні зміни. Якщо, наприклад, без синтаксичної форми вам знадобиться змінити декілька різних розташувань коду або перемістити фрагменти в інші місця, то це не цукор.
Однак, синтаксичний цукор є чудовим при правильному використанні. Я думаю, що будь-який програміст схеми, швидше за все, буде 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 синтаксис замість того, щоб вручну вводити синтаксис ітератора.
Вся перевантаження оператора - це чистий синтаксичний цукор.
Це звучить як справедливе і досить однозначне визначення?
"Синтаксичний цукор" не є строго визначеним терміном. Залежно від того, кого ви запитуєте, ви, швидше за все, отримаєте одне з наступних видів визначень: