OberonCore

Пока не нашёл... Архив издательства этого журнала начинается только с 2002 г., более старых нет...
Нашёл ссылки на этот язык в учебных программах ИММ УрО РАН:

http://pmf.vidicor.ru/School/index.htm

Прохоров В.В., Прохорова М.Ф. Система функционального программирования на языке PROLAN/F // Проблемы теоретической и прикладной математики. Информационные материалы. Свердловск: УрО РАН, 1990. С.60

Судя по всему, интересная книга, но не в открытом доступе:
Школьник и компьютер - учимся друг у друга
Год: 1993
УДК: 519.68

Ну, вообще-то я догадываюсь, откуда идут корни этого PROLAN/F - очень похожий на этот язык псевдокод был описан в книге Питера Хендерсона "Функциольнальное программирование. Применение и реализация"

Не, ну не скажите... В Prolan/M чётко видно, что на что меняется, а в птичьем брейнфаке голову сломать можно... :о))


А Вы знаете, для реализации функциональности оператора IF-THEN-ELSE никакие CMP/Jxx не нужны... ;о)

Краткое введение в лямбда-исчисление

Ну функциональные языки - вещь весьма экзотическая и "на новенького" вполне себе "бреинфачная" (хотя некоторые вещи там пишутся нагляднее). А CMP/Jxx нужны, но в этом случае к ним ещё добавится PUSH...CALL...RET (для рекурсии).

Ну хорошо, вот простейший вариант функционального варианта IF-THEN-ELSE:
Здесь функция true принимает два параметра, возвращает первый, второй игнорирует;
функция false принимает два параметра, возвращает второй, а первый - игнорирует.
Функция iff является функцией высшего порядка (ФВП) - принимает в качестве первого параметра другую функцию, которую тут же вызывает, передав ей свои второй и третий параметры...

Например, в следующей программке:
a будет равна 1, а b, соответственно, 2...

Ну где тут CMP/Jxx ??? Нету их! :о))

По семантике IF cначала должно проверяться условие, а не исполняться ветка.

Какая ветка? Вы про энергичные вычисления? Ну так чистое ФП обычно лениво, и какое-либо выражение вычисляется только когда оно становится нужным. Сначала условие, а затем - нужная ветка, всё верно... ;о)

Кстати, в том же Обероне операции AND, OR тоже ленивы - второй аргумент вычисляется только при необходимости...

Я бы подчеркунул не только "при необходимости", но и "при фактической возможности". Т.е. полагаясь на гарантированную ленивость, мы можем писать более лаконичные выражения (в частности, условия циклов).

Интересно, в каком порядке компилятор обходит IF - слева направо или справа налево? Это прописано в спецификации? А то будет стоять какая-то функция, которая что-то делает, а он её раз и отключит... Вот и "грабли"...


В некоторых случаях это будет трюкачеством в стиле игр с префиксной-постфиксной формами операторов инкремента и декремента в Си...

Причём тут трюкачество, сокращённое вычисление логических выражений - стандарт в современных языках.
Если в выражении (A & B) A дало FALSE, то B не вычисляется, т.к. его значение не влияет на результат выражения.
Если в выражении (A OR B) A дало TRUE, то B не вычисляется.
Это позволяет красиво записывать условия, к примеру, в линейном поиске:
WHILE (list # NIL) & (list.x # 10) DO list := list.next END.
С математической точки зрения грамотнее, т.е. если первый операнд осмысленен и целиком определяет результат операции, то неосмысленность второго операнда не оказывает никакого влияния на осмысленность операции в целом.

Иначе пришлось бы писать:
WHILE (list # NIL) & ~found DO
IF list.x = 10 THEN
found := TRUE
ELSE
list := list.next
END
END, потом посмотреть, плюнуть - и начать воротить цикл с BREAK...

Выражение в грамотно составленной программе не должно иметь побочных эффектов (что-то менять в состоянии) - это аксиома. Поэтому вычисляется ли реально какая-то его часть или нет - никакого значения не имеет, важен только его результат.

Нет не про вычисление, а про оператор IF ( т.е. о функции высокого порядка, конечно). Как бы она передала аргумент, не вычислив его? Отсюда и замечание.

Не, я понял, я не Вам отвечал, а на сообщение ScrollLock-а

Я согласен, но для Вашего примера надо знать наверняка, в каком направлении компилятор разберёт выражение (справа налево или слева направо). Если это (как и невычисление "лишних" выражений) прописано в спецификации на язык или компилятор, тогда всё в порядке... А то в противном случае недалеко и до исключения или даже "программа выполнила некорректную операцию" (когда что-то попытаются сделать с пустым элементом).

А если функций ввода-вывода не запихивать в сложные выражения - тогда конечно не трюкачество . Хотя что-то в стиле (имя функции и тип данных - условные)
IF OpenFile("file") # NIL THEN
...
ELSE
...
END
так и напрашивается (частенько такое встречается) - функция-то одна.

Порядок вычисления и сокращённое вычисление определены стандартом языка Оберон/КП. Кстати, как и стандартом С++/Ява/чё там ещё.

IF OpenFile("file") # NIL THEN
- а тут смысла нет. Всё равно полученный объект надо использовать, а потому Вы будете сначала присваивать его чему-либо.
И OpenFile, вообще говоря, можно в конктексте прикладного кода считать функцией без побочных эффектов. Для вашего модуля от факта открытия файла ничего не меняется...

А вообще, об этом думают разработчики функций. В КП никогда не описывают функцию с побочными эффектами. Если они есть, то возврат значения идёт через OUT-параметр.

Зачем так категорично? Вы не используете, а кто-то использует. Язык ведь такое не запрещает

Функция, которая что-то делает - это процедура с побочными эффектами.
Хороший стиль программирования требует запрета на вызов подобных процедур внутри условия цикла или IF. Следуйте этому запрету - и граблей не будет... :о)


Кстати, в Аде есть оба варианта - и энергичные and/or, и ленивые and then/or else.

Вообще, вот это меня удивляет в поздних виртовских языках - Модуле-2 и Обероне.
Что за такая мания к сокращению набора ключевых слов - & вместо AND, ~ вместо NOT, даже нестандартный # вместо <> или /= или |= ... Зачем такие сокращения? Какая от них выгода? Только ухудшение читабельности...

А в чём проблема-то? Как приняла, так и передала - зачем вычислять то выражение, результат которого не понадобится?
Фактически же из функции в функцию передаются не сами выражения, а лишь ссылки на них. Когда выражение понадобится, то оно вычисляется по этой ссылке, вот и всё...

А напрасно не запрещает
Просто в учебных курсах, по которым учат основные участники Информатики-21, это сразу говорится ученикам, и ещё грозится пальчиком: "Ай-яй, если нарушать - то по рукам..." Отсюда и такая категоричность...

Всё идёт этак поэтапно. Когда-то на словах запретили GOTO/BREAK, а фактически его оставляли в языках. Но и то, под влиянием пропаганды, использование по крайней мере GOTO уменьшилось до терпимого уровня. Потом исключили из некоторых особо хороших языков вообще. Основное внимание "словесного внушения" пошло уже на более тонкие моменты типа побочных эффектов А там не за горой и их компиляторный контроль

Я совершенно согласен, что некоторые случаи употребления этих функций в IF-ах (особенно по несколько штук)- "грабли". Но запрещать функции действия - это уже экстремизм, из языка их не исключишь: иначе как обращаться к Windows API или к множеству графических библиотек (напр, OpenGL)? А ведь Windows и OpenGL - это продукты мирового класса. Очевидно, люди решили не городить указателей, там где это излишне (это я про возврат значения через OUT-параметр).
А насчёт остальных не очень структурных вещей: по читаемости и нужности получается ряд break>continue>goto. В Обероне цикл LOOP способен избавить от соблазна "лепить" goto в некоторых случах (типа поиска элемента в двухмерном массиве).
P.S. А про открытие файла - у меня просто перед глазами был вот такой код - в нём вроде бы "граблей" не видно (кстати, очень часто встречается)

Обычно вызовы WinAPI и внешних не-ООП библиотек остаются только на самом нижнем уровне, тут же оборачиваются и закрываются собственными высокоуровневыми интерфейсами. Естественно, на низком уровне взаимодействия с окружением без таких поблажек не обойтись, как и без SYSTEM. Речь идёт об основных частях систем.

Так уже же есть такие компиляторы - для Хаскелла, например... ;о)