Ответ на »сообщение 3746« (Илья Ермаков)
___________________________

т.п.) и процедуры-функции с возвращаемым значением.
С последними все ясно - принято, что они не имеют побочного эффекта внутри и снаружи (все параметры функций - только по значению или по IN-ссылке). К сожалению, стандартом языка (в отличие от Ады) не запрещено описать функцию вида, например, Func (OUT retVal: INTEHGER): BOOLEAN - но на практике так никто не делает. С возвращаемыми значениями в Обероне описывают только чистые функции.

Я тоже так думал, однако вот первая попавшаяся функция из BlackBox (модуль TextControllers):

PROCEDURE CachedReader (c: StdCtrl): TextModels.Reader;
  VAR rd: TextModels.Reader;
BEGIN
  rd := c.text.NewReader(c.cachedRd); c.cachedRd := NIL; RETURN rd
END CachedReader;

Состояние передаваемого параметра c беспардонно меняется в функции.
Вот и думаю - имеет ли смысл придерживаться правила чистоты функций?

Ответ на »сообщение 3738« (Руслан Богатырев)
___________________________
>>>Итак, у нас есть модуль M, который является элементом общей системы и который подвергается модификации/расширению. Он предоставляет интерфейс-контракт, в котором фигурируют используемые сущности (константы, переменные, типы, процедуры). Постулируется, что если модификация не изменяет требований контракта (только расширяет его либо изменяет реализацию), то теоретически это не оказывает влияния на всю систему в целом.
Вот конкретный случай: для некоторого специализированного скриптового языка был разработан модуль, позволяющий заменять используемый в скрипте параметр. Я смело использовал этот модуль в своей программе и был очень доволен. Появилась новая версия - она позволяла заменять параметр в скрипте и в тех случаях, когда он встречается многократно. Я заменил модуль, убедился, что он работает. Через год у одного из заказчиков программа стала зависать. Трассировка привела к функции подстановки параметров. Слава богу исходные тексты удалось добыть и найти ошибку. Кто может догадаться, какую ошибку допустил разработчик в такой простой процедуре, как процедура замены в тексте, что она стала циклится при определенном (редком) сочетании входных параметров?
Заметте, что к языку программирования все это отношения не имеет - это результат отчуждения модуля.

Ответ на »сообщение 3722« (Руслан Богатырев)
___________________________
В Компонентном Паскале взяли схему, близкую к Аде: VAR, IN и OUT. Т.е. для передачи по значению не указывается ничего (режим всегда in), а при передачи по ссылке "квалифицируется" характер передачи -- in, out или inout.
Руслан, в Аде слова in, out и inout НИКАКОГО ОТНОШЕНИЯ к определению способа передачи (по значению/по ссылке) АБСОЛЮТНО НЕ ИМЕЮТ.

Ответ на »сообщение 3759« (Илья Ермаков)
___________________________
Пара замечаний Илья.

Высота и скорость в автопилоте - в операционной трактовке одинаковые типы. В содержательной - разные. И если вывести операционный тип компилятор может автоматически, то указать содержательный тип не может никто, кроме самого программиста...

Как раз хаскель и позволяет описать содержательный тип и соответственно следить чтобы высота и скорость не перемешивались. При чем именно выводом типов.

Возвращая результат "как результат" будем иметь либо а) оверхед на копирование, если возвращаем структуру данных статически б) либо оверхед на динамику, если будем использовать только динамические структуры.

Оверхеда на копирование в чистых ФЯ нет ваабче как класса.
Подумайте сами. Если данные ВСЕГДА readonly, то какой смысл копировать ? Ведь ссылку передавать безопасно. Язык гарантирует что с данными по этой ссылке никто ничего сделать не сможет.
А значит всегда и везде можно передавать ссылки и не заморачиваться копированием, автобоксингом и прочими особенностями императивной жизни.

Ответ на »сообщение 3699« (Geniepro)
___________________________
Хм, ну тогда в таких языках, как Хаскелл, вообще нет никаких стандартных функций и операций. +, -, *, / и пр., циклические операции над списками (map, foldr, foldl, take, drop и пр.) - всего этого нет в виде языковых конструкций. Всё это определено как методы стандартных классов и стандартные функции.
А в Форте ваще НИЧЕГО нет...
Куда вы его "вывернете" (ООП, ФП, ишшо какой зверушк) - ограничено тока вашей фантазией, и временем, и возможностью не умереть с голоду на срок реализации и ухода от мэйнстримовской кармушки... :о)

Ответ на »сообщение 3748« (Geniepro)

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

Действительно, если убрать wallpaper такой эффект пропадает...
Я думал дело не воллпейпере... Старался не кликать по столу :)
Но эффект похоже не повторяется если поставить потом другой wallpaper.

Насколько реальное приложение? - http://sage.h15.ru/?e1l1
Там же по поводу кириллических кодировок для Blebottle - http://sage.h15.ru/?e1l2

Ответ на »сообщение 3754« (pepper)
___________________________
Если на минутку представить, что оберон не идеален, то можно заметить, что проблема с "помечанием" входа/выхода элементарно и красиво решается, если просто запретить менять входные параметры, а результат возвращать как результат. Что мы и имеем в чистых функциональных языках. При этом не надо никаких высоких размышлений о "кардинальном отличии процедур от функций", все очевидно.

А в чистых логических языках вообще не парятся с тем, чтобы различать входные и выходные параметры.

Но "кардинальное отличие" никуда не девается. Поэтому в чистых функциональных языках приходится обращаться к высоким размышления о "действиях" и их комбинировании или к не менее высоким размышления о "состоянии мира" и функциях, манипулирующих этим состоянием.

Ответ на »сообщение 3712« (Jack Of Shadows)
___________________________

Ответ на »сообщение 3709« (Руслан Богатырев)
Н: Чушь, тип переменной в подавляющем большинстве случаев однозначно проистекает от опереации над ней производимой.

Ну, Джек, Вы же всегда ратовали за абстрактность :-) И вдруг "зависаете" на уровне операционной типизации. А если смотреть на ТД не как на множество значений + совокупность операций, а как на указание содержательной роли данных в программе?
Высота и скорость в автопилоте - в операционной трактовке одинаковые типы. В содержательной - разные. И если вывести операционный тип компилятор может автоматически, то указать содержательный тип не может никто, кроме самого программиста... И таким ли полезным в таком ракурсе становится автовывод типа, и не лучше ли явное его указание?
Подход с автовыводом - подход математика, которому достаточно операционной типизации, и которого мало волнует явное указание "физического смысла" данных...

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

Ответ на »сообщение 3754« (pepper)
___________________________

Ответ на »сообщение 3746« (Илья Ермаков)
___________________________
Что мы и имеем в чистых функциональных языках. При этом не надо никаких высоких размышлений о "кардинальном отличии процедур от функций", все очевидно.
Жалко, что Вам не очевидно, что подходы к конструированию ПО бывают разные. У нас это "кардинальное отличие" существует, если у Вас его нет - я рад за Вас :-)

Ответ на »сообщение 3740« (AVC)

Не огорчайтесь так. :)
Попробуем проконсультироваться у SAGE.

Всё дело в архивах...

WinAos containing Oberon as external (Windows) window:  WinAos3.02e.zip
(Oberon-GUI closer to Windows Oberon) - запускается Native Oberon

WinAos containing Oberon as internal (Bluebottle) window: WinAos3.02i.zip
(GUI closer to native Bluebottle operating system) - запускается GUI Bluebottle