Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 3766 08-04-2007 15:48 | |
Ответ на »сообщение 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 беспардонно меняется в функции.
Вот и думаю - имеет ли смысл придерживаться правила чистоты функций?
№ 3765 08-04-2007 15:48 | |
Ответ на »сообщение 3738« (Руслан Богатырев)
___________________________
>>>Итак, у нас есть модуль M, который является элементом общей системы и который подвергается модификации/расширению. Он предоставляет интерфейс-контракт, в котором фигурируют используемые сущности (константы, переменные, типы, процедуры). Постулируется, что если модификация не изменяет требований контракта (только расширяет его либо изменяет реализацию), то теоретически это не оказывает влияния на всю систему в целом.
Вот конкретный случай: для некоторого специализированного скриптового языка был разработан модуль, позволяющий заменять используемый в скрипте параметр. Я смело использовал этот модуль в своей программе и был очень доволен. Появилась новая версия - она позволяла заменять параметр в скрипте и в тех случаях, когда он встречается многократно. Я заменил модуль, убедился, что он работает. Через год у одного из заказчиков программа стала зависать. Трассировка привела к функции подстановки параметров. Слава богу исходные тексты удалось добыть и найти ошибку. Кто может догадаться, какую ошибку допустил разработчик в такой простой процедуре, как процедура замены в тексте, что она стала циклится при определенном (редком) сочетании входных параметров?
Заметте, что к языку программирования все это отношения не имеет - это результат отчуждения модуля.
№ 3764 08-04-2007 15:39 | |
Ответ на »сообщение 3722« (Руслан Богатырев)
___________________________
В Компонентном Паскале взяли схему, близкую к Аде: VAR, IN и OUT. Т.е. для передачи по значению не указывается ничего (режим всегда in), а при передачи по ссылке "квалифицируется" характер передачи -- in, out или inout.
Руслан, в Аде слова in, out и inout НИКАКОГО ОТНОШЕНИЯ к определению способа передачи (по значению/по ссылке) АБСОЛЮТНО НЕ ИМЕЮТ.
№ 3763 08-04-2007 15:23 | |
Ответ на »сообщение 3759« (Илья Ермаков)
___________________________
Пара замечаний Илья.
Высота и скорость в автопилоте - в операционной трактовке одинаковые типы. В содержательной - разные. И если вывести операционный тип компилятор может автоматически, то указать содержательный тип не может никто, кроме самого программиста...
Как раз хаскель и позволяет описать содержательный тип и соответственно следить чтобы высота и скорость не перемешивались. При чем именно выводом типов.
Возвращая результат "как результат" будем иметь либо а) оверхед на копирование, если возвращаем структуру данных статически б) либо оверхед на динамику, если будем использовать только динамические структуры.
Оверхеда на копирование в чистых ФЯ нет ваабче как класса.
Подумайте сами. Если данные ВСЕГДА readonly, то какой смысл копировать ? Ведь ссылку передавать безопасно. Язык гарантирует что с данными по этой ссылке никто ничего сделать не сможет.
А значит всегда и везде можно передавать ссылки и не заморачиваться копированием, автобоксингом и прочими особенностями императивной жизни.
№ 3762 08-04-2007 15:03 | |
Ответ на »сообщение 3699« (Geniepro)
___________________________
Хм, ну тогда в таких языках, как Хаскелл, вообще нет никаких стандартных функций и операций. +, -, *, / и пр., циклические операции над списками (map, foldr, foldl, take, drop и пр.) - всего этого нет в виде языковых конструкций. Всё это определено как методы стандартных классов и стандартные функции.
А в Форте ваще НИЧЕГО нет...
Куда вы его "вывернете" (ООП, ФП, ишшо какой зверушк) - ограничено тока вашей фантазией, и временем, и возможностью не умереть с голоду на срок реализации и ухода от мэйнстримовской кармушки... :о)
№ 3761 08-04-2007 14:15 | |
Ответ на »сообщение 3748« (Geniepro)
Гоняясь за этими зайцами и скелетами заметил, что нужно немедленно убирать wallpaper, иначе весь интерфейс, все кнопки уменьшаются и ничего не понятно...
Интересно, её можно использовать для создания реальных приложений?
Действительно, если убрать wallpaper такой эффект пропадает...
Я думал дело не воллпейпере... Старался не кликать по столу :)
Но эффект похоже не повторяется если поставить потом другой wallpaper.
Насколько реальное приложение? - http://sage.h15.ru/?e1l1
Там же по поводу кириллических кодировок для Blebottle - http://sage.h15.ru/?e1l2
№ 3760 08-04-2007 14:08 | |
Ответ на »сообщение 3754« (pepper)
___________________________
Если на минутку представить, что оберон не идеален, то можно заметить, что проблема с "помечанием" входа/выхода элементарно и красиво решается, если просто запретить менять входные параметры, а результат возвращать как результат. Что мы и имеем в чистых функциональных языках. При этом не надо никаких высоких размышлений о "кардинальном отличии процедур от функций", все очевидно.
А в чистых логических языках вообще не парятся с тем, чтобы различать входные и выходные параметры.
Но "кардинальное отличие" никуда не девается. Поэтому в чистых функциональных языках приходится обращаться к высоким размышления о "действиях" и их комбинировании или к не менее высоким размышления о "состоянии мира" и функциях, манипулирующих этим состоянием.
№ 3759 08-04-2007 14:05 | |
Ответ на »сообщение 3712« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3709« (Руслан Богатырев)
Н: Чушь, тип переменной в подавляющем большинстве случаев однозначно проистекает от опереации над ней производимой.
Ну, Джек, Вы же всегда ратовали за абстрактность :-) И вдруг "зависаете" на уровне операционной типизации. А если смотреть на ТД не как на множество значений + совокупность операций, а как на указание содержательной роли данных в программе?
Высота и скорость в автопилоте - в операционной трактовке одинаковые типы. В содержательной - разные. И если вывести операционный тип компилятор может автоматически, то указать содержательный тип не может никто, кроме самого программиста... И таким ли полезным в таком ракурсе становится автовывод типа, и не лучше ли явное его указание?
Подход с автовыводом - подход математика, которому достаточно операционной типизации, и которого мало волнует явное указание "физического смысла" данных...
(Я сейчас не трогаю конкретные языков. Про то, что атомарная типизация в Обероне не поднимается выше операционного уровня, я уже говорил - и причины назывались. А в Хаскеле за счет субтипизации ее можно "поднять" до содержательного уровоня. В Обероне же содержательная типизация делается только на основе RECORD).
№ 3758 08-04-2007 13:55 | |
Ответ на »сообщение 3754« (pepper)
___________________________
Ответ на »сообщение 3746« (Илья Ермаков)
___________________________
Что мы и имеем в чистых функциональных языках. При этом не надо никаких высоких размышлений о "кардинальном отличии процедур от функций", все очевидно.
Жалко, что Вам не очевидно, что подходы к конструированию ПО бывают разные. У нас это "кардинальное отличие" существует, если у Вас его нет - я рад за Вас :-)
№ 3757 08-04-2007 13:55 | |
Ответ на »сообщение 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
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|