Страница 1 из 2
Об операторных скобках и отступах
Добавлено: 23.10.2007 10:51:40
Bonart
Один из известных недостатков Паскаля - его структурные операторы с единственным оператором в качестве тела цикла или альтернативы, что приводило к непрозрачности кода (висячий else) иего многословности (сплошные begin..end).
В Аде все структурные операторы уже включают в себя операторные скобки - избавились от кучи лишних begin'ов и ошибок, связанных с одиночными-составными операторами. Но для простых случаев лаконичность ухудшилась - каждый раз надо писать endif, endloop и т.д.
В Питоне вместо операторных скобок - отступы. Это хорошо для больших блоков, но плохо смотрится для маленьких плюс неудобно для автоматической генерации исходных текстов.
Я предлагаю использовать подход из Haskell - взаимозаменяемость операторных скобок и отступов.
Ключевое понятие - операторы с одним и тем же отступом - считаются последовательными и находящимися на одном уровне. Заодно это позволяет отказаться от разделителей операторов, если их не больше одного на строку.
Т.е.
эквивалентно
Код: Выделить всё
оператор1; begin оператор2; оператор3 end; оператор4
Для условного оператора
Код: Выделить всё
if условие then оператор1 else оператор2 end; оператор3
Эквивалентно
Код: Выделить всё
if условие
оператор1
else
оператор2
оператор3
then (открывающая операторная скобка) и endif(закрывающая) операторная скобка, а также точка с запятой (разделитель) успешно заменены отступами.
Причем можно и так
Код: Выделить всё
if условие then оператор1 else оператор2
оператор3
Закрывающая скобка endif заменена отступом - оператор3 имеет тот же уровень, что и if)
Добавлено: 23.10.2007 12:31:36
bw
Как питонозаводчик я поддерживаю идею, но:
> Это хорошо для больших блоков, но плохо смотрится для маленьких плюс неудобно для автоматической генерации исходных текстов.
Про генерацию ничего не скажу, а вот про не красиво:
Ты считаешь что это не красиво? Если я тебя не правильно понял, приведи пример.
Это в защиу Python'а, а по существу... в том же "if" я считаю обязательно должен быть "then".
..bw
Добавлено: 23.10.2007 12:59:53
Bonart
bw писал(а):Ты считаешь что это не красиво? Если я тебя не правильно понял, приведи пример.
Мне двоеточия не нравятся. И обязательность для else отдельной строки.
bw писал(а):В том же "if" я считаю обязательно должен быть "then".
Что предлагаемое решение в случае записи в одну строку
требует
А в несколько -
позволяет как
так и
В зависимости от собственных предпочтений программиста по части лаконичности и прозрачности кода операторные скобки можно свободно как опускать (а-ля Питон), так и указывать явно (традиционные языки).
Добавлено: 23.10.2007 14:38:38
bw
> А в несколько - позволяет как
> ...
> так и
> ...
Первый вариант я считаю лишним, как и вообще двойственность в синтаксисе.
..bw
Добавлено: 23.10.2007 15:20:08
Bonart
bw писал(а):Первый вариант я считаю лишним, как и вообще двойственность в синтаксисе.
Какая двойственность?
Никаких двойных трактовок у приведенных примеров нет!
А вот возможность двумя способами оформить одно и то же сама по себе не криминал, если служит улучшению читабельности, лаконичности и эффективности кода.
Ведь для реализации любого алгоритма хватит простой последовательности и цикла с предусловием - но таких драконовских ограничений ни в одном распространенном языке нет.
Так и здесь - есть возможность писать короткие операторы в одну строку с явными скобками и разделителями, а большие - "лесенкой" без "шумовых" символов, что лишь повышает читабельность.
Это повышает КПД кодера - плодами его усилий по оформлению текста сможет воспользоваться не только коллега, но и компилятор!
Добавлено: 24.10.2007 00:00:50
Deepthroat
А вот возможность двумя способами оформить одно и то же сама по себе не криминал
Криминал. Будешь рассматривать чужие исходники, оформленные то таким способом, то другим, а то и вообще смешанным - не раз проклянешь такую демократичность языка. Мне кажется очень и очень разумным положение типа "одна задача - одно решение". Существенно упрощает работу в коллективе и работу с чужими исходниками. Кроме того, упрощается синтаксис языка ("далай так" вместо "делай так, или так, а можно еще так, так и так, а еще можно комбинировать способы 2 и 3, а также 1, 3 и 4"). Соответственно, язык проще освоить. А из-за строгости и однозначности уменьшается возможность допустить ошибку.
Думаете, просто так люди выбирают PHP, а не Perl для Web? PHP - язык четкий, там не особо-то и разгуляешься (а PHP 6 будет построен вообще по принципу "одна задача - один оператор"), тогда как Perl допускает множество способов сделать одно и то же, ооочень гибкий синтаксис. А в результате, Perl сложно выучить, сложно разобраться в чужих исходниках.
Добавлено: 24.10.2007 07:20:15
Bonart
Deepthroat писал(а):Мне кажется очень и очень разумным положение типа "одна задача - одно решение".
С такой логикой из всех структурных операторов можно оставить только цикл while. Для функциональной полноты его достаточно.
Deepthroat писал(а):PHP - язык четкий, там не особо-то и разгуляешься
Про "четкий" язык PHP - это в юмор.
Deepthroat писал(а):Думаете, просто так люди выбирают PHP, а не Perl для Web?
Думаю, что дело в низком пороге вхождения у PHP плюс его доступности практически на любом хостинге.
Deepthroat писал(а):Существенно упрощает работу в коллективе и работу с чужими исходниками.
Ну-ну. Отступы визуализируют операторные скобки для людей. Сами скобки и разделители делают то же самое для компилятора. Ручное слежение за соответствием одного другому, оказывается, сильно "упрощает" работу с чужими исходниками.
Зато ситуация, когда отступы одинаково читаются и людьми и компилятором - это, конечно, "плохо".
Добавлено: 25.10.2007 01:15:15
Deepthroat
Хорошо, оставим PHP - не тот форум и не та тема, чтобы его обсуждать.
Ручное слежение за соответствием одного другому, оказывается, сильно "упрощает" работу с чужими исходниками.
Дословно, я говорил это:
Мне кажется очень и очень разумным положение типа "одна задача - одно решение". Существенно упрощает работу в коллективе и работу с чужими исходниками.
Т.е. упрощает принцип "одна задача - одно решение", а не "Ручное слежение за соответствием одного другому". Причем, в моем варианте, никакого соответствия не требуется, т.к. этого "другого" просто нету.
Зато ситуация, когда отступы одинаково читаются и людьми и компилятором - это, конечно, "плохо".
А где я говорил, что отступы - плохо? Я писал лишь о том, что нужно оставить одну возможность и не больше. Но я не говорил, какую.
P.S. Вы мое сообщение не прочитали полностью, потому не правильно поняли, а потом просто выцепили фразы из контекста и ответили на то, чего я не говорил. Из-за этого мне пришлось повторяться и разъяснять свое предыдущее сообщение. А это надо другим участникам дискуссии? Думаю, что нет.
Так что, обращаясь ко всем, давайте уважать друг друга и читать сообщения полностью. Хотя бы те, на которые отвечаете. Если сообщение кажется большим и читать его влом, то лучше оставить его вообще без ответа.
Добавлено: 25.10.2007 16:28:15
Bonart
Deepthroat писал(а): писал лишь о том, что нужно оставить одну возможность и не больше. Но я не говорил, какую.
Так одна возможность в ряде ситуаций неудобна.
Разделители неудобны для больших составных операторов, отступы неудобны для маленьких составных операторов, спокойно помещающихся в одну строку, и автоматической генерации исходников.
Deepthroat писал(а):P.S. Вы мое сообщение не прочитали полностью
Я его прочитал целиком. Требование оставить одно посчитал необоснованным. Почему - пояснил. В Паскале три цикла, хотя по теории хватает одного. Но с одним - неудобно.
Добавлено: 27.12.2007 21:46:16
VaSys
Вот вы говорите о локаничности кода, его читабельности, о том как бы помочь программисту разбирая чужой код. Хотите что-то изменить (для этого обычного нужно что-то поломать, а ломать - не сторить). Зачем?
Не проще ли всторить утилитку которая будет приводить исходный код к статндартному виду, с определенными отступами, выравниванием и прочим! И проблема решится. Добавьте возможность скрытия операторных скобок, при отформатированом тексте, и забудете про надоедливые begin...end;
Re: Об операторных скобках и отступах
Добавлено: 19.06.2008 15:51:38
Bonart
Не проще ли всторить утилитку которая будет приводить исходный код к статндартному виду, с определенными отступами, выравниванием и прочим!
Не проще. Такая утилитка будет привязывать программиста к конкретной платформе, среде разработки или просто к себе.
А зачем, когда предлагаемая возможность спокойно реализуется компилятором?
Re: Об операторных скобках и отступах
Добавлено: 20.06.2008 09:43:04
Timid
Мое личное мнение - проблема не в избыточности языка программирования, а в редакторе.
Если удасться создать редактор, который будет автоматически структурировать документ (код), обладать сверткой, подсвечивать синтаксис, использовать фреймы для просмотра кода вызываемых процедур и т.п., то проблем не будет.
Сильно упрощенный пример - castalia для delphi.
Кстати, может организовать проект на сайте - castalia для freepascal/лазарь - как встраиваемый редактор?
Re: Об операторных скобках и отступах
Добавлено: 28.01.2009 15:29:58
perlpunk
если хотя бы была возможность использовать синтаксис модулы или оберона (без кейворда begin, определение модулей с помощью module) ито уже было бы лучше
Re: Об операторных скобках и отступах
Добавлено: 18.03.2009 20:54:30
alexraynepe196
попробуйте ознакомица с введением к PRECC,
там как раз обсуждались сложности реальзации парсера OCCAM на yyacc\yylex.
причина сложностей в том что сложно в BNF описать грамматику с полями переменной параметризованой длины
тобиш тот самый отступ заданного размера.
вдобавок разные системы по разному обрабатывают табы, и если программер использовал табы для отступов
, скажем по неосторожности, то как их должен парсер обработать?
пойдем дальше, скажем программер сделал отступы пробелами, но вот он использовал стороннюю прогу для
форматирования текста а она переделала отступы по своему. и ето только самый явный пример как длина отступа
может потерятся.
вобчем имхо правильно древние рассудили что использование форматирования для описания алгоритма - ЗЛО.
Re: Об операторных скобках и отступах
Добавлено: 18.03.2009 21:15:44
alexs
Люди - не надо фортран изобретать.
Всё что вы описали (особенно с отступами) - это суть - Фортран 77 и раньше.