MODULE  sgTest003;
IMPORT  StdLog;

PROCEDURE   Проверка*;
  TYPE A = POINTER TO ARRAY 10000000 OF INTEGER;
  VAR a: A;
BEGIN
  StdLog.String(" Создаю "); StdLog.Ln();
  NEW(a);    (* В этом месте я вижу через Windows Task Manager  как BlackBox забрал
память*)
  StdLog.String(" Выхожу из области видимости "); StdLog.Ln();
  a := NIL; (* Я думаю, что сборщик мусора должен активизироваться в этом месте *)
END Do;
(* В этом месте я ожидаю, что BlackBox отдаст память обратно в распоряжение Windows
XP*)

BEGIN
END  sgTest003.

(Коммандер)sgTest003.Проверка

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

В той форме, в которой она велась, она достала всех посещающих форум.

Ну вот, теперь хоть проясняется, что виновата, оказывается, форма, а не конкретно языки. Что касается формы, то чему удивляться: если кто-то кого-то куда-то неоднократно посылает, а другие (включая и тех, кому по рангу положено) спокойно на это смотрят, никак не одергивают конкретного человека (интересно же, чем закончится), то что потом руками разводить. Зато потом -- всенародный гнев и возмущение. Как это по-нашему.

Bingo! Прелесть этого утверждения в том, что именно оно, несмотря на свою простоту, указывает на Оберон, как на единственный выбор.

Неужели Вы думаете, что если столь чтимый мной классический Оберон выдвигается на уникальное место сомнительным для меня критерием, то я это безоговорочно приму? Отнюдь. Истина дороже.

Если бы я из знал... Возможно что-то вроде Sheme (но точно ни Common Lisp, ни Smalltalk). Еще мини-язык Дейкстры есть

Проблема в том, что чистота инвариантов -- не очень практичная вещь. Это надежность, но никак не практичность. И даже Scheme Гая Стила на этот пьедестал вряд ли может быть возведен.

В КП метапрограммирование не нарушает это правило.

Метапрограммирование -- это средство из разряда трансформации исходных текстов на лету. Очень сильнодействующий механизм. Похлеще нейрохирургии.

В КП же во первых метопрограммирование вынесено в библиотеки, а во вторых, в документации тому же к модулю Meta (ЧЯ), говориться, что он позволяет делать только то, что позволяют правила языка, ни больше, ни меньше.

Будем говорить точнее: не в КП, а в КП/BlackBox. Не стоит забывать, что есть еще КП/GPCP (даже несколько -- для разных операционных и инструментальных платформ). И потом это не правила языка, а правила доступа к его реализации и к формированию исходников. Детали реализации в описании того же КП (как и других Оберонов) практически не оговариваются (что и понятно).

Мое утверждение о инвариантах может быть резким или провокационным, но существует определенная категория людей, которые могут легко с ним согласится.

Инварианты, безусловно очень важная, фундаментальная вещь программирования. И тем, кто знаком с работами Эдсгера Дейкстры, Дэвида Гриса, Чарльза Хоара, А.П.Ершова это наверняка понятно. Ершов, если не ошибаюсь, так вообще предлагал бить по рукам программиcта, если тот не выявлял инвариант цикла до написания самого цикла. Все это ближе к сфере доказательного программирования. Достойная тема. Но выходит за рамки Оберонов. И, кстати, имеет не самое последнее отношение к языку Eiffel Бертрана Мейера. Бертрана, а не Бертранда, ибо он француз.

Ответ на »сообщение 41« (Руслан Богатырев)
___________________________


Существуют модули, в которых содержится исключительно "тупой" код алгоритмов и для которых (при одинаковом интерфейсе) есть разные по эффективности версии реализации. Могут ли теоретически такие модули подменяться на лету (т.е. выгружаться одна версия и тут же загружаться другая)? Имеет ли смысл вообще при решении задач загрузки-выгрузки принимать во внимание и подобную "категорию"/"маркировку" модуля?

ИМХО, теоретически это возможно.
Даже без выгрузки импортирующих модулей.
Насколько это целесообразно -- вопрос.

Конечно есть альтернативный метод защиты системных инвариантов: это разделение системы на процессы, с аппаратной защитой памяти процессов от
взаимного влияния.
В этом смысле UNIX можно написать на любом языке, но не на любом языке можно написать ОС Оберон.

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


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

Наверное, должен. (Это логично.)
Но мне кажется, это мало поможет в данном случае.
Оберон-технология характеризуется не только орграфом динамически подгружаемых модулей, но и составными документами, содержащими в своем составе произвольные объекты.
Модуль, обеспечивающий загрузку и "поддержку" соответствующего документа, может не иметь ссылки на "свой" объект. Эта ссылка размещается в документе.
Поэтому вопрос о возможности и целесообразности выгрузки модулей, ИМХО, остается неясным.
Конечно, есть ситуации, когда выгоды выгрузки модулей очевидны, а минусов (вроде бы) нет.
Например, при написании-компиляции-отладке нового модуля.
Но это отдельная ситуация, а не общее правило.


Между прочим, какой-нибудь дополнительный механизм, наподобие сборки в .NET, мог бы решить эту проблему.
Угу... Но вопервых не гарантируется что на все случаи жизни, "net effect could be negative..." (c) Гуткхнехт.

Я имел в виду идею добавить подобный механизм в Оберон, а не использовать непосредственно .NET. :)

Ответ на »сообщение 41« (Руслан Богатырев)
___________________________

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


Существуют модули, в которых содержится исключительно "тупой" код алгоритмов и для которых (при одинаковом интерфейсе) есть разные по эффективности версии реализации. Могут ли теоретически такие модули подменяться на лету (т.е. выгружаться одна версия и тут же загружаться другая)? Имеет ли смысл вообще при решении задач загрузки-выгрузки принимать во внимание и подобную "категорию"/"маркировку" модуля?

Эээ... не понял вопроса.

Ответ на »сообщение 40« (Руслан Богатырев)
___________________________


Насчет порочности -- слишком резко сказано.

В основном для четкости выражения мысли. Дискуссия итак уже стала достаточно запутанной, что бы выискивать мысли за оговорками и умолчаниями. Опять же, при желании, IMHO расставлять по вкусу.

Если дискуссия достала конкретного человека, то совсем не значит, что она достала всех.

В той форме, в которой она велась, она достала всех посещающих форум.

Это так, в качестве небольшой ремарки. И если уж достала, то зачем к ней возвращаться?

Ни к какому соглашению, а так же пониманию причин разногласий, в итоге не пришли.

Если следовать Вашей логике, то отказать в праве называется языком для практического использования надо почти всем известным языкам программирования.

Bingo! Прелесть этого утверждения в том, что именно оно, несмотря на свою простоту, указывает на Оберон, как на единственный выбор.

Не могли бы Вы перечислить 3-5 языков, удовлетворяющих Вашему критерию?

Если бы я из знал... Возможно что-то вроде Sheme (но точно ни Common Lisp, ни Smalltalk). Еще мини-язык Дейкстры есть ^_^

Не могли бы Вы также пояснить, как в Вашей шкале ценностей рассматривается механизм метапрограммирования, возможности которого здесь достаточно наглядно продемонстрировал Илья Ермаков? Его нет в языке Компонентный Паскаль. Но он есть в конкретной реализации языка в среде BlackBox. Этот механизм удовлетворяет Вашему критерию или нет?

Я не сказал бы, что это моя безусловная ценность, но оно может безусловно служить ориентиром в мире IT. В КП метапрограммирование не нарушает это правило. Например вхождение его в язык Ява вызывает определенные проблемы, в том числе есть попытки создать подмножества Явы, не имеющие этого свойства. В КП же во первых метопрограммирование вынесено в библиотеки, а во вторых, в документации тому же к модулю Meta (ЧЯ), говориться, что он позволяет делать только то, что позволяют правила языка, ни больше, ни меньше.

Дополнительное замечание: мое утверждение о инвариантах может быть резким или провокационным, но существует определенная категория людей, которые могут легко с ним согласится. Это люди с физическим background'ом (начиная с того же Дейкстры). Поскольку для физика (тем более теоретического) понятие инварианта является фундаментальным, он вряд ли сможет согласится с допустимостью его нарушения по каким бы то ни было соображениям. Законы сохранения, термодинамики, принцип неопределенности не могут быть отброшены, из-за того что детям в школе трудно их усваивать. Многие из поклонников Оберона на этом форуме признавались, что пошли прямо физического факультета или аспирантуры (меня можно отнести к последней категории) и в этом смысле нужно делать поправку на аудиторию.

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


Существуют модули, в которых содержится исключительно "тупой" код алгоритмов и для которых (при одинаковом интерфейсе) есть разные по эффективности версии реализации. Могут ли теоретически такие модули подменяться на лету (т.е. выгружаться одна версия и тут же загружаться другая)? Имеет ли смысл вообще при решении задач загрузки-выгрузки принимать во внимание и подобную "категорию"/"маркировку" модуля?

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

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

Насчет порочности -- слишком резко сказано. Разумеется, надо отличать модуль от компонента. Модульное программирование от компонентного программирования. И просто понимать, что это несколько разные вещи.

Это может быть так же аргументом во всех доставшей дискуссии О2-КП. Аргумент против О2, а так же С, Ява, С# и прочих: язык допускающий нарушение установленных программистом инвариантов не пригоден для практического использования. ^_^

Если дискуссия достала конкретного человека, то совсем не значит, что она достала всех. Это так, в качестве небольшой ремарки. И если уж достала, то зачем к ней возвращаться?

Если следовать Вашей логике, то отказать в праве называется языком для практического использования надо почти всем известным языкам программирования.

Не могли бы Вы перечислить 3-5 языков, удовлетворяющих Вашему критерию?

Не могли бы Вы также пояснить, как в Вашей шкале ценностей рассматривается механизм метапрограммирования, возможности которого здесь достаточно наглядно продемонстрировал Илья Ермаков? Его нет в языке Компонентный Паскаль. Но он есть в конкретной реализации языка в среде BlackBox. Этот механизм удовлетворяет Вашему критерию или нет?

Вообще попытка утверждение, что модуль = компонент, мне кажется порочным. Модуль может быть основой для создания компонентной системы (допускающей динамическую загрузку/выгрузку) компонентов, а может и не быть (если это не требуется для решения конкретной задачи).

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

Это может быть так же аргументом во всех доставшей дискуссии О2-КП. Аргумент против О2, а так же С, Ява, С# и прочих: язык допускающий нарушение установленных программистом инвариантов не пригоден для практического использования. ^_^

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

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

Поэтому я не стал бы уподоблять выгрузку обероновского модуля завершению работы приложения в обычной ОС.
Приложение существует в отдельном адресном пространстве, поэтому его и можно выгрузить без особых проблем. Про выгрузку обероновского модуля такого не скажешь.

Тем не менее программы так же могут быть связаны многочисленными средствами IPC. Аналогично можно безопасно выгружать лишь программы не взаимодействующие с другими.

Между прочим, какой-нибудь дополнительный механизм, наподобие сборки в .NET, мог бы решить эту проблему.
Угу... Но вопервых не гарантируется что на все случаи жизни, "net effect could be negative..." (c) Гуткхнехт.