Блоки кодаТакже как и в Python, блоки кода в 11l выделяются посредством отступов (пробелов или табуляций): F sum(a, b) R a + b[Здесь объявляется функция sum, возвращающая сумму двух её аргументов.] Но 11l также поддерживает явное обозначение блоков посредством фигурных скобок, благодаря которому можно объявить эту же функцию без отступа: F sum(a, b) { R a + b } или в одну строку: F sum(a, b) {R a + b} И такой стиль также поддерживается: F sum(a, b) { R a + b } И такой: F sum(a, b) { R a + b } И такой: F sum(a, b) { R a + b } Мои мысли на тему ‘whitespace indentation to delimit code blocks’\‘выделение блоков кода с помощью отступов’/‘«двухмерного» синтаксиса Python-а’
«Двухмерный» синтаксис помимо избавления от [мелкого] синтаксического
Проиллюстрирую это на примере документации к языку Nemerle: https://github.com/rsdn/nemerle/wiki/...: Скорее всего, разработчики Nemerle просто скопировали это из Haskell или Standard ML, не став даже разбираться в причинах указанного "stupid bug with dangling-else". А причина вовсе не в неправильной логике if [допускающем как отсутствие ветви else, так и её наличие], и даже не в забытых фигурных скобочках, а в... расхождении в восприятии данного кода человеком-программистом и компилятором. Человек воспринимает границы блоков визуально, посредством отступов, а компилятор — посредством [малоприметных для человека] символов, причём компилятор [языков C/C++, C#, Java, Nemerle и др.] объединяет все "пробельные" символы [разделители], и, таким образом, напрочь игнорирует отступы. Вот в этом и заключается корень проблемы — компилятор и человек видят [такой] код по-разному. Поэтому меня удивляют люди, которые ‘‘жалуются на трудность и непривычность чтения такого кода’’, а также возражения, что ‘‘при изменении лишь отступа, меняется логика работы кода’’. Так в этом и состоит весь смысл отступо-зависимой семантики! Ведь такое изменение отступа будет хорошо заметно человеку (особенно привыкшему к такой семантике). А для желающих временно добавить if, включающий в себя большой блок кода [который не хочется сдвигать лишний раз], я считаю, что вполне можно оставить поддержку фигурных скобок: if foo // временно добавленное условие { m1() // нет отступа относительно if foo ... if bar m2() ... ... } http://compiler.su/dvukhmernyj-sintaksis-python.php:Согласен. По сути, это двоеточие в Python не имеет смысла, так как есть операторы (if, for/while, def, class и т.д.), которые требуют всегда нового scope, и одного признака ‘‘новая строка с отступом’’ вполне достаточно. Кстати, весьма интересна история появления этого двоеточия. http://python-history.blogspot.com/2011/07/...:То есть, scientists, разработчики языка программирования, прислушались к мнению человека, не имеющего никакого отношения к программированию? Они хотели таким образом упростить понимание языка для новичков? Но новичком программист остаётся только короткое время в начале своего пути, а лишние двоеточия наблюдать и набирать придётся и дальше. Не думаю, что так уж сложно привыкнуть к их отсутствию... if условие: выражение) и циклы, но выйти из положения можно с помощью обозначения scope в фигурных скобках (запись if условие {выражение}) как в Rust, либо взяв условие в скобки ( if (условие) выражение). В крайнем случае, я считаю, вполне возможно это двоеточие вынести в настройки проекта. И команды разработчиков, которые примут у себя в качестве стандарта [кодирования] запись с двоеточием, будут писать с двоеточием, а кто не хочет [следовать такому стандарту] — пусть пишут без двоеточия. На уровне компилятора реализовать пропуск двоеточия в конце строки для нескольких операторов совсем несложно. Или можно на уровне IDE сделать опциальное отображение двоеточия в конце строк, начинающихся на I/if, E/else, F/fn, L/loop, S/switch, T/type и т.д. |