geniepro писал(а):
Добавить одну процедурку -- это лишний чих???
Насколько я понял, ты имеешь ввиду не процедурку, а ключевое слово языка, разве не так?
geniepro писал(а):
Неужели оберонщиков и правда устраивает такая ситуация, при которой приходится плодить тонны невнятного говнокода? И всё из-за соображений какого-то там минимализма...
geniepro, верно ли я понял тебя, что Оберон неплохой язычок, но одним из самых его больших недостатков является минимализм, а в контексте нашего разговора — то, что невозможно игнорировать результат процедуры с помощью рулезного ключевого слова ignore? И есть ещё много хороших слов, которых несомненно не хватает Оберону, таких как virtual, method, inline, volatile, static, public, protected, private, stdcall, fastcall, cdecl и т.д. И их отсутствие порождает у оберонщиков тонны говнокода и лично оскорбляет твой эстетический вкус? А то ведь добавить их в Оберон можно и нужно.
Но, дорогой, с ними получится уже не Оберон. Получится плохая Ада, да и то в лучшем случае.
И по каждому слову можно подискутировать, нужно ли оно в языке. Или достаточно системного префикса (или атрибута). А в ряде случаев — более умного поведения компилятора.
Теперь ещё по поводу игнорирования результата процедур. Здесь было предложено два способа: высокоэффективный системный (но непереносимый) с PUTREG и несистемный (и переносимый), записанный как IF Proc() = 0 THEN END;
Действительно это философский вопрос — стоит ли игнорировать результат. Работая с винапи (или с тем же libc) правильный ответ — да. И проблема здесь коренится не только в, возможно, корявом проектировании, а в том, что интерфейсы библиотек (dll и so) являются процедурными. Есть и объектно-ориентированные интерфейсы, как в Java .class'ах, но Оберон тем и хорош, что предлагает нам модульные интерфейсы, которые включают в себя и процедурные, и ОО, и добавляют кое-что ещё. Так вот, обероновские модульные интерфейсы предоставляют прекрасную возможность игнорировать результат процедур-методов красиво. Ессно, если только это понадобится. При умелом проектировании такая игнорация не столь уж необходима, но умелому проектированию надо долго учиться!
Проиллюстрирую подход примером. В XDev/WinDev есть модуль Files, проектируя который я стремился сделать работу с файлами удобной и безопасной, а также позволяющей обрабатывать возникающие ошибки с разной степенью детализации (углубления в подробности). Вот как выглядит работа с файлами с полным игнором ошибок создания-записи-закрытия файла:
Код: "OBERON"
MODULE FilesTest; IMPORT Files;
VAR
file: Files.FileToWrite;
BEGIN (*$MAIN*)
file.OpenToWrite("Hello.txt"); file.WriteStr("Hello World!"); file.Close;
END FilesTest. (* Ай-яй-яй, никогда не игнорируйте ошибки, а то будет бобо! *)
Благодаря тому, что любые файловые операции с данным файлом после возникновения ошибки игнорируются, ничего ужасного на любой стадии работы с файлом не произойдёт. Никаких runtime error и предложений послать отчёт дяде Биллу. В самом страшном случае файл просто не создастся.
Первая степень детализации при обработке ошибок — определение только факта наличия ошибки, при этом проверять можно после каждой файловой операции:
Код: "OBERON"
LOOP
file.OpenToWrite("Hello.txt");
IF file.error THEN (* Проблемы с созданием файла для записи. *) EXIT END;
file.WriteStr("Hello World!");
IF file.error THEN (* Проблемы с записью данных в файл. *) EXIT END;
file.Close;
IF file.error THEN (* Проблемы с закрытием файла. *) EXIT END;
(* А вот здесь у нас всё в порядке, не паримся! *)
EXIT
END(*LOOP*)
Либо же после целой группы файловых операций:
Код: "OBERON"
file.OpenToWrite("Hello.txt");
file.WriteStr("Hello World!");
file.Close;
IF file.error THEN (* Что-то пошло не так. *)
ELSE
(* Всё отлично, файл создался успешно. *)
END;
Здесь ошибка могла произойти где угодно, но все последующие после неё операции с файлом игнорировались, переменная error (как флажок возникновения ошибки) оставалась неизменно TRUE, а код ошибки доступен в дополнительной переменной для анализа, чтобы понять, что именно произошло. Вот это и есть вторая степень детализации, когда после файловой операции (или группы операций) недостаточно только факта наличия ошибки, а нужно ещё и уточнить её вид, анализируя код ошибки. Текст программы не привожу, идея понятна.
Не призываю избегать обработки ошибок. Не утверждаю, что модуль Files спроектирован идеально правильно и красиво. Просто показываю, что игнорация (а, вернее, опциональная обработка результата) легко достигается средствами Оберона без всяких ключевых слов типа ignore.
geniepro советую не сводить все Обероны к Оберону-07. Есть прекрасный КП. Есть здравые идеи в AO. Вирт ясно показал нам, что нужно конструировать языки под решаемые задачи. Излишнюю зацикленность на Обероне-07, отмежевание от КП (и даже от Оберона-2) в сторону "идеологически чистого, единственно правильного, одобренного дядькой Виртом и кошерного Оберона-07", в котором минимализм действительно доведён почти до невозможности использования, считаю смешным. КП это тоже Оберон, и не намного больше его.
А есть ещё такое математическое расширение, как
OberonX, вообще рвёт. Там даже операции "+" и "-" можно переопределять. И небольшое.
Есть, наконец, расширение GPCP, в которое включен 64-битный тип LONGSET, а также обработка исключений и ещё несколько интересных фишек.
Поэтому программист, даже опытный и знающий много рулезных языков, не может адекватно рассуждать о том, что нужно добавить в Оберон, пока очень вдумчиво не поработает, решая на Обероне те задачи, которые он решает. Чтобы произвести обоснованное мнение о целесообразности доработки Оберона в том или ином направлении — ценен опыт работы именно на Обероне, а не на других языках (особенно функциональных или гибридно-функциональных, у которых совсем другая идеология, а часто и назначение). Это всё равно если монах-католик будет рассуждать о реформах, которые надо принять в православной церкви. Нет, господа, этот мёд нужно есть изнутри банки, а снаружи на него можно только смотреть, вовсю рассуждая о его вкусе. "Я Битлз не слушал, мне Мойше по телефону напел. Но другие-то группы я слушаю постоянно!".
Оберон развивается, надо просто развивать его не огульно, добавляя что попало откуда попало, а усилиями точными и умелыми, как движения скульптора.