Дизайн синтаксису - навіщо використовувати круглі дужки, коли не передаються аргументи?

У багатьох мовах синтаксис function_name(arg1, arg2, ...)використовується для виклику функції. Коли ми хочемо викликати функцію без будь-яких аргументів, ми повинні це зробити function_name().

Мені здається дивним, що компілятору чи інтерпретатору сценарію потрібно ()буде успішно виявити його як виклик функції. Якщо змінна, як відомо, називається, чому її не function_name;вистачить?

З іншого боку, в деяких мовах ми можемо зробити: function_name 'test';або навіть function_name 'first' 'second';викликати функцію чи команду.

Я думаю, що круглі дужки були б кращими, якби вони були потрібні лише для оголошення порядку пріоритетності, а в інших місцях були необов’язковими. Наприклад, дія if expression == true function_name;повинна бути такою ж справедливою, як і if (expression == true) function_name();.

На мою думку, найприємніше робити це, 'SOME_STRING'.toLowerCase()коли явно не потрібні аргументи функції прототипу. Чому дизайнери вирішили проти простішого 'SOME_STRING'.lower?

Відмова: Не зрозумійте мене неправильно, я люблю C-подібний синтаксис! ;) Я просто запитую, чи може бути краще. Чи вимагає ()якісь переваги у виконанні, чи це полегшує розуміння коду? Мені дуже цікаво, в чому саме причина.

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

a = object.functionName

в той час як акт виклику цієї функції такий:

b = object.functionName()

aу наведеному вище прикладі було б посилання на вищевказану функцію (і ви можете її назвати виконуючи a()), тоді як bмістило б повернене значення функції.

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

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

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

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

Проходження параметрів не є єдиною визначальною характеристикою виклику методу. Чому я ставлюся до методу без параметрів, відмінного від методу, який має параметри?

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

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

leq : int * int -> bool
leq (a, b) = a <= b

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

leq some_pair = some_pair.1 <= some_pair.2

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

А як щодо функції, яка нібито не має аргументів? Така функція фактично має домен Unit. Одиночний член елемента, Unitяк правило, записується як " ()," тому в них виникають дужки.

say_hi : Unit -> string
say_hi a = "Hi buddy!"

Щоб викликати цю функцію, нам доведеться застосувати її до значення типу Unit, яке має бути (), тому ми закінчимо запис say_hi ().

Отже, насправді не існує такого поняття, як список аргументів!

Наприклад, у Javascript, використовуючи ім'я методу без (), повертає саму функцію, не виконуючи її. Таким чином, ви можете, наприклад, передати функцію як аргумент іншому методу.

У Java було зроблено вибір, що ідентифікатор, за яким слідує () або (...), означає виклик методу, тоді як ідентифікатор без () посилається на змінну члена. Це може покращити читабельність, оскільки ви не сумніваєтесь, чи маєте ви справу зі способом чи змінною члена. Насправді, те саме ім'я можна використовувати як для методу, так і для змінної члена, обидва будуть доступні у відповідному синтаксисі.

Синтаксис слідує за семантикою, тому почнемо з семантики:

Які способи використання функції чи методу?

Насправді існує кілька способів:

• функцію можна викликати з аргументами або без них
• функція може трактуватися як значення
• функція може бути частково застосована (створення закриття, що бере принаймні один менший аргумент і закриття переданих аргументів)

Наявність подібного синтаксису для різних цілей є найкращим способом створити або неоднозначну мову, або, принаймні, заплутану мову (а таких у нас достатньо).

На мовах, подібних до С та С:

• виклик функції здійснюється за допомогою дужок, щоб укласти аргументи (може бути жодного), як у func()
• трактування функції як значення може бути виконано просто використанням її імені як у &func(C, створення покажчика функції)
• у деяких мовах у вас є синтаксиси, які частково застосовуються; Java дозволяє, someVariable::someMethodнаприклад, (обмежується приймачем методу, але все ще корисно)

Зауважте, як кожне використання має різний синтаксис, що дозволяє легко їх розрізняти.

Мовою з побічними ефектами IMO дуже корисно розмежовувати (теоретично без побічних ефектів) читання змінної

variable

та виклик функції, яка може спричинити побічні ефекти

launch_nukes()

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

Жодна з інших відповідей не намагалася вирішити питання: скільки зайвих у дизайні мови має бути? Тому що навіть якщо ви можете спроектувати мову так, щоб x = sqrt yвстановити х до квадратного кореня у, це не означає, що ви обов'язково повинні.

Мовою без надмірності кожна послідовність символів щось означає, а це означає, що якщо ви зробите одну помилку, ви не отримаєте повідомлення про помилку, ваша програма зробить неправильну річ, яка може бути щось зовсім інше, ніж ви призначений і дуже важкий для налагодження. (Як буде знати кожен, хто працював із регулярними виразами.) Невелика надмірність - це хороша річ, оскільки вона дозволяє виявити багато ваших помилок, і чим більше надмірності є, тим більше шансів на те, що діагностика буде точною. Тепер, звичайно, ви можете зайняти це занадто далеко (ніхто з нас не хоче писати в COBOL в ці дні), але є баланс, який є правильним.

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

У більшості випадків це синтаксичний вибір граматики мови. Граматика корисна для різних індивідуальних конструкцій (відносно) однозначно, якщо їх узяти разом. (Якщо є неоднозначності, як, наприклад, у деяких деклараціях C ++, повинні бути конкретні правила для вирішення.) У компілятора немає широти для здогадок; потрібно дотримуватися мовної специфікації.

Visual Basic в різних формах розрізняє процедури, які не повертають значення, та функції.

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

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

(З іншого боку , Visual Basic використовує ті ж дужки ()для посилань на масиви як для викликів функцій, тому посилання на масив виглядають виклики функцій. І це полегшує ручну рефакторинг масиву в виклик функції! Таким чином, ми могли б подумати інші мови використовують []«пд.ш. для посилань на масив, але я відхиляюсь ...)

На мовах C і C ++ до вмісту змінних автоматично звертається за допомогою їх імені, і якщо ви хочете посилатися на саму змінну замість її вмісту, ви застосовуєте одинарний &оператор.

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

Це цілком правдоподібно (як і інші синтаксичні варіанти для цього).

Послідовність і читабельність.

Якщо я дізнаюся , що ви викликаєте функцію Xна зразок цього: X(arg1, arg2, ...), то я очікую , що це працює так само , як для будь - яких аргументів: X().

Тепер в той же час я дізнаюся, що ви можете визначити змінну як деякий символ і використовувати її так:

a = 5
b = a
...

А що я міг би подумати, коли знайду це?

c = X

Ваша здогадка така ж, як і моя. У звичайних обставинах значення Xє змінною. Але якби ми пішли на ваш шлях, це також може бути функцією! Чи слід пам’ятати, який символ символізує групу (змінні / функції)?

Ми можемо накласти штучні обмеження, наприклад, "Функції починаються з великої літери. Змінні починаються з малої літери", але це не потрібно і ускладнює справи, хоча іноді може допомогти деяким із цілей дизайну.

Побічна примітка 1: Інші відповіді повністю ігнорують ще одне: мова може дозволяти вам використовувати те саме ім’я як для функції, так і для змінної та відрізняти за контекстом. Дивіться Common Lispяк приклад. Функція xта змінна xспівіснують ідеально.

Побічна примітка 2: Прийнятий відповідь показує нам синтаксис: object.functionname. По-перше, це не є універсальним для мов з першокласними функціями. По-друге, як програміст я ставлюся до цього як до додаткової інформації: functionnameналежить до object. Будь- objectякий об’єкт, клас чи простір імен - це не так вже й важливо, але це говорить мені, що він десь належить . Це означає, що вам потрібно або додати штучний синтаксис object.для кожної глобальної функції, або створити деякі, objectщоб утримувати всі глобальні функції.

І в будь-якому випадку ви втрачаєте можливість мати окремі простори імен для функцій та змінних.

Щоб додати до інших відповідей, візьміть цей приклад C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

void example()
{
        ff = func_factory;
        ff = func_factory();
}

Якщо оператор виклику був необов’язковим, не було б можливості розрізнити призначення функції та виклик функції.

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