Чи чіткіші оператори для читання, ніж ключові слова чи функції? [зачинено]

Це трохи суб'єктивно, але я сподіваюся отримати більш чітке розуміння того, які чинники роблять оператора зрозумілим у використанні проти тупих і складних. Нещодавно я розглядав мовні конструкції, і одне питання, над яким я завжди кружлю, - це коли зробити якусь ключову операцію на мові оператором і коли використовувати ключове слово чи функцію.

Haskell дещо відомий для цього, оскільки користувацькі оператори легко створювати, і часто новий тип даних поставляється в комплекті з декількома операторами для використання на ньому. Наприклад, бібліотека Parsec постачається з безліччю операторів для комбінування парсерів разом із дорогоцінними каменями, >.і .> я навіть не можу пригадати, що вони означають зараз, але я пам’ятаю, що з ними було дуже просто працювати, коли я запам’ятав, що вони насправді означають. Чи буде виклик функції, такий як leftCompose(parser1, parser2)був кращим? Безумовно, більш багатослівний, але в деяких відношеннях більш чіткий.

Перевантаження операторів на мовах, подібних до С, є подібною проблемою, але пов'язаною з додатковою проблемою перевантаження значення звичних операторів, як, наприклад, +з незвичними новими значеннями.

У будь-якій новій мові це може здатися досить важким питанням. Наприклад, у F # для кастингу використовується оператор кастингу типів, отриманий математично, замість синтаксису відливання стилю C # або багатослівного стилю VB. C #: (int32) xVB: CType(x, int32)F #:x :> int32

Теоретично нова мова може мати операторів для більшості вбудованих функціональних можливостей. Замість defабо decабо varдля оголошення змінної, чому немає ! nameабо @ nameабо що - щось подібне. Це, безумовно, скорочує декларацію з наступним прив'язкою: @x := 5замість declare x = 5або let x = 5 Більшість кодів вимагає багато змінних визначень, так чому б і ні?

Коли оператор зрозумілий і корисний, а коли він затьмарений?

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

Усі ці рішення зрештою зводиться до того, як ви хочете, щоб нотація читалася, і як, як ви говорите, суб'єктивна, хоча можна зробити кілька очевидних раціоналізацій, наприклад, використовувати звичайні оператори інфікування для математики, як їх усі знають

Нарешті, Дайкстра написав цікаве обґрунтування використовуваних ним математичних позначень , що включає гарне обговорення компромісів нофіксів та префіксів

Для мене оператор перестає бути корисним, коли ви більше не можете читати рядок коду вголос чи в голові, і це має сенс.

Наприклад, declare x = 5читати як "declare x equals 5"чи let x = 5можна читати як "let x equal 5", що дуже зрозуміло, коли читати вголос, проте читання @x := 5читається як "at x colon equals 5"(або "at x is defined to be 5"якщо ви математик), що зовсім не має сенсу.

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

Оператор зрозумілий і корисний, коли він знайомий. І це, ймовірно, означає, що операції з перевантаженням слід робити лише тоді, коли обраний оператор знаходиться в достатній близькості (як у формі, пріоритетності та асоціативності), як уже встановлена ​​практика.

Але копаючи трохи далі, є два аспекти.

Синтаксис (інфікс для оператора на відміну від префікса для синтаксису виклику функції) та іменування.

Для синтаксису є ще один випадок, коли інфікс досить чіткий, ніж префікс, що може вимагати ознайомлення із зусиллями: коли виклики є ланцюговими та вкладеними.

Порівняйте a * b + c * d + e * fз +(+(*(a, b), *(c, d)), *(e, f))або + + * a b * c d * e f(обидва можна проаналізувати в тому ж стані, що і версія інфіксації). Той факт, що +окремі терміни замість того, щоб передувати одному з них довгим способом, роблять його більш читабельним у моїх очах (але ви повинні пам’ятати правила пріоритету, які не потрібні для синтаксису префікса). Якщо вам потрібно скласти речі таким чином, довгострокова вигода повинна бути вартістю навчання. І ви зберігаєте цю перевагу, навіть якщо ви називаєте своїх операторів літерами замість символів.

Щодо імен операторів, я бачу мало переваг у використанні чогось іншого, ніж встановлені символи чи чітка назва. Так, вони можуть бути коротшими, але вони справді загадкові і швидко забудуться, якщо у вас немає вагомих причин вже їх знати.

Третій аспект, якщо ви користуєтесь мовним дизайном POV - це якщо набір операторів має бути відкритим чи закритим - можна додати оператора чи ні - і якщо пріоритет та асоціативність повинні бути визначеними користувачем чи ні. Першим моїм заходом було б бути обережним і не надавати визначений користувачем пріоритет та асоціативність, тоді як я буду більш відкритим щодо наявності відкритого набору (це збільшить натиск на використання перевантаження оператора, але зменшить рівень використання поганого просто скористатися синтаксисом інфіксації там, де це корисно).

Оператори як символи корисні, коли вони інтуїтивно мають сенс. +і -, очевидно, є додаванням і відніманням, наприклад, саме тому майже кожна мова коли-небудь використовує їх як своїх операторів. Те ж сама з порівнянням ( <і >вчать в початковій школі, а також <=і >=інтуїтивні розширення основних порівнянь , коли ви розумієте , що немає ніякої підкресленого-порівняння клавіші на стандартній клавіатурі.)

*і /менш очевидні, але вони використовуються універсально, і їх положення на цифровій клавіатурі поруч із клавішами +та -допомагає забезпечити контекст. C <<і >>знаходяться в одній категорії: коли ти розумієш, що таке зсув вліво і вправо, не дуже складно зрозуміти мнемоніку за стрілками.

Потім ви переходите до справді дивних, речей, які можуть перетворити код C у нечитабельний суп оператора. (Вибираючи тут C, тому що це дуже важкий для оператора приклад, з синтаксисом якого майже всі знайомі, як через роботу з C, так і з мовами нащадків.) Наприклад, тоді %оператор. Усі знають, що це: знак відсотка ... так? За винятком C, це не має нічого спільного з поділом на 100; це оператор модуля. Це має нульовий сенс мнемонічно, але є!

Ще гірше булеві оператори. &як і має сенс, за винятком того, що є два різні &оператори, які роблять дві різні речі, і обидва синтаксично дійсні в будь-якому випадку, коли один з них є дійсним, хоча тільки один з них насправді має сенс у будь-якому випадку. Це просто рецепт плутанини! Оператори or , xor і не є ще гіршими, оскільки вони не використовують мнемонічно корисних символів, а також не є послідовними. (Немає оператора double- xor , а логічний і бітовий не використовувати два різних символи замість одного символу та подвоєної версії.)

І просто , щоб зробити його гірше, &і *оператори отримують повторно використовувати для абсолютно різних речей, що робить мову більш важким для людей , так і компіляторів для синтаксичного аналізу. (Що A * Bозначає? Це повністю залежить від контексту: це Aтип чи змінна?)

Щоправда, я ніколи не розмовляв з Деннісом Річі і не питав його про дизайнерські рішення, які він приймав мовою, але так багато з цього відчуває, що філософія операторів була "символами заради символів".

Порівнюйте це з Pascal, який має ті ж оператори, що і C, але інша філософія в їх представленні: оператори повинні бути інтуїтивними та легкими для читання. Арифметичні оператори однакові. Оператор модуля - це слово mod, оскільки на клавіатурі немає жодного символу, який очевидно означає «модуль». Логічні оператори and, or, xorі not, і є тільки один друг; компілятор знає, чи потрібна вам булева або побітова версія на основі того, чи ви працюєте з булевими чи числами, усуваючи цілий клас помилок. Це робить код Pascal набагато простішим для розуміння, ніж код C, особливо в сучасному редакторі з підсвічуванням синтаксису, тому оператори та ключові слова візуально відрізняються від ідентифікаторів.

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

Однак я боровся з операторами швидкого доступу для таких функцій, як fold. Очевидно, що більше досвіду з ними полегшило б це, але я вважаю, що foldRightце читає більше, ніж /:.

Проблема операторів полягає в тому, що їх існує лише невелика кількість порівняно з кількістю чутливих (!) Імен методів, які можна використовувати замість цього. Побічним ефектом є те, що визначені користувачем оператори, як правило, вводять багато перевантажень.

Звичайно, рядок C = A * x + b * cпростіше писати і читати, ніж C = A.multiplyVector(x).addVector(b.multiplyScalar(c)).

Або, ну, це, звичайно, простіше написати, якщо у вас в голові всі перевантажені версії всіх цих операторів. І ви зможете прочитати його згодом, виправляючи помилку другого за останнім.

Тепер для більшості кодів, які там будуть працювати, це добре. "Проект проходить усі тести, і він працює" - для багатьох програмне забезпечення, це все, що ми могли хотіти.

Але все виходить інакше, коли ви працюєте з програмним забезпеченням, яке переходить у критичні місця. Критичні питання безпеки. Безпека. Програмне забезпечення, яке підтримує літаки в повітрі або підтримує роботу ядерних установок. Або програмне забезпечення, яке шифрує ваші дуже конфіденційні листи.

Для експертів з безпеки, які спеціалізуються на аудиторському коді, це може бути кошмаром. Сукупність безлічі визначених користувачем операторів і перевантаження операторів може поставити їх у неприємну ситуацію, що їм важко з'ясувати, який код буде працювати в кінцевому підсумку.

Отже, як сказано в первісному питанні, це дуже суб’єктивний предмет. І хоча багато пропозицій про те, як використовувати операторів, можуть здаватися абсолютно чуйними, поєднання лише декількох з них може створити багато проблем у довгостроковій перспективі.

Я вважаю, що самий крайній приклад - APL, наступна програма - "гра життя":

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

І якщо ви зможете розібратися, що все це означає, не витрачаючи пару днів на довідник, тоді удачі вам!

Проблема полягає в тому, що у вас є набір символів, який майже всі інтуїтивно розуміють: +,-,*,/,%,=,==,&

і решта, які потребують певного пояснення, перш ніж їх можна зрозуміти, і, як правило, характерні для конкретної мови. Наприклад, немає явного символу, який би вказував, який член масиву ви хочете, [], () і навіть ". були використані, але в рівній мірі немає очевидного ключового слова, яке ви могли б легко використати, тому є необхідний випадок для розумного використання операторів. Але їх не надто багато.