Чому спільнота Lisp вважає за краще накопичувати всі дужки в кінці функції?

Чому спільнота Lisp воліє накопичувати всі дужки в кінці функції:

(defn defer-expensive [cheap expensive]
  (if-let [good-enough (force cheap)]
    good-enough
    (force expensive)))

Чому б не застосувати такий конвент, як C або Java?
Ну гаразд, Лісп набагато старший за ці мови, але я говорю про сучасних Лісперсів.

(defn defer-expensive [cheap expensive]
  (if-let [good-enough (force cheap)]
    good-enough
    (force expensive)
  )
)

Примітка: фрагмент коду - з книги "Радість клоджура".

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

if (pred)
{
  printf("yes");
}

легко зійти і додати ще одне твердження в дужки:

if (pred)
{
  printf("yes");
  ++yes_votes;
}

Якби початкова форма була

if (pred)
{ printf("yes"); }

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

І навпаки, у Ліспа бракує тверджень; кожна форма є вираженням , приносячи деяку цінність - навіть якщо в деяких рідкісних випадках (маючи на увазі загального Ліса), це значення навмисно вибирається таким, що не має значення без порожньої (values)форми. Рідше можна знайти послідовності виразів , на відміну від вкладених виразів . Бажання "відкрити послідовність кроків до розмежувача, що закривається" виникає не так часто, тому що, коли заяви й відходять, а значення повернення стають більш звичною валютою, рідше ігнорувати повернене значення виразу, а отже, і більше рідко можна оцінити послідовність виразів лише для побічного ефекту.

У Common Lisp prognформа є винятком (як і її побратими):

(progn
  (exp-ignored-return-1)
  (exp-ignored-return-2)
  (exp-taken-return))

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

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

Закриття дужок набагато менше імпорту, ніж відступ форми, де вони відкриваються. З часом людина вчиться ігнорувати дужки та писати та читати за формою - так, як це роблять програмісти Python. Однак не дозволяйте, щоб ця аналогія наштовхнула вас на думку про те, що цілком видаляти круглі дужки було б доцільно. Ні, для цього найкраще зберегти дискусію comp.lang.lisp.

Бо це не допомагає. Ми використовуємо відступи для показу структури коду. Якщо ми хочемо розділити блоки коду, ми використовуємо дійсно порожні рядки.

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

(Для мене питання полягає в тому, чому програмісти на C і Java люблять кидати свої брекети.)

Просто для того, щоб продемонструвати, припускаючи, що ці оператори були доступні на мові, подібній С:

Foo defer_expensive (Thunk cheap, Thunk expensive) {
    if (Foo good_enough = force (cheap)) {
        return good_enough; }
    else {
        return force (expensive); }}

Два дужки закривають два рівні гніздування. Синтаксис очевидно правильний. Аналогічно синтаксису Python, дужки - це явні лексеми INDENT та DEDENT.

Звичайно, це може бути не ^ТМ «єдиний справжній брекет-стиль» , але я вважаю, що це лише історична випадковість і звичка.

Код тоді набагато компактніший. Рух у редакторі все-таки здійснюється за допомогою s-виразів, тому вам не потрібен простір для редагування. Код читається здебільшого за структурою та реченнями, а не за наступними роздільниками.

Слухачі, ви знаєте, ненависно блестячі, як це може бути, є певний je ne sais quoi до другого прикладу:

(defn defer-expensive [cheap expensive]
  (if-let [good-enough (force cheap)]
    good-enough
    (force expensive)
  )
)

Спочатку я не міг покласти пальцем джерело принади, так би мовити, а потім зрозумів, що він просто не вистачає тригера:

(defn defer-expensive [cheap expensive]      
  (if-let [good-enough (force cheap)]
    good-enough   ;   )
    (force expensive) 
  )
)

Вуаля!

Я зараз буду займатися моїм бандитським захватом Lisp!

У моєму випадку я вважаю, що рядки, присвячені розмежувачам, марно витрачаються на екранний простір, і коли ви пишете код на C, також існує стиль

if (pred) {
   printf("yes");
   ++yes_votes;
}

Чому люди ставлять вступну дужку в ту саму лінію "якщо", щоб заощадити простір, і тому, що здається зайвим мати свою лінію, коли "якщо" вже має свою лінію.

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

{if (pred)
    printf("yes");
}

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

if (pred) {
    printf("yes");
}

дає чітке уявлення про блок та його межі за допомогою '{' & '}'

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

(defn defer-expensive [cheap expensive]
    _(if-let [good-enough (force cheap)]
    good-enough
    (force expensive)_))

ви можете помістити курсор у закриваючий парен у середині та мати параметр відкриття для if-let.