Короче, дайте программисту исследовательский полигон, и вы добьетесь радикального улучшения в качестве программ.

Полностью согласен. Одна из основных идей Оберон-сред.

Ну вот давайте и поговорим об обероне как исследовательском полигоне.
Об ФП будем говорить в соответствующей ветке. А здесь вопросы к вам.

1. Основной чертой исследовательского полигона является интерпретатор. Возможность вручную запустить любую функцию и посмотреть результат, не загружая для этого программу.
На этом построен лисп. Интерпретатор есть в erlang, python, ruby. Есть даже в таком статически компилируемом языке как хаскель.

А как с этим дела обстоят в обероне ?

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

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

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

»сообщение 6063« Илья Ермаков
Спасибо за четкий ответ.

Ответ на »сообщение 6062« (Сергей  Кузнецов)
___________________________

Если вариант 1 не верен, то подскажите где можно ознакомиться с работой сборщика мусора.
Классический алгоритм Mark&Sweep. Почитать можно где угодно. С конкретной ББ-реализацией можно познакомиться в исходниках модуля Kernel (был документирован - http://wiki.oberoncore.ru/index.php/BlackBox:Kernel).

Ответ на »сообщение 6062« (Сергей  Кузнецов)
___________________________
Все 10 блоков будут освобождены при очередной сборке мусора (через некоторое конечное время, например, при одном из очередных NEW либо при простое приложения). Специально после выхода из процедуры сборка мусора, естественно, не выполняется - слишком дорогостоящая процедура.

Локальные переменные инициализируются в NIL, если они имеют тип POINTER, ANYPTR или PROCEDURE. Прочие переменные не инициализируются и содержат мусор.

Как сработает сборщик мусора в BB после выполнения следующей процедуры?
  PROCEDURE p1;
  VAR i:INTEGER;    d:POINTER TO ARRAY OF CHAR;
  BEGIN
    FOR i:=0 TO 9 DO NEW(d,256) END
  END p1;

Вариант 1. Освободит все 10 блоков.
Вариант 2. Освободит 9 (кроме последнего).
Вариант 3. Все 10 блоков не будут освобождены.

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

Вот еще пример из достоверных источников:

Блэкбокс используется в Verizon Inc. с 1997 г. -- некая система тестирования с графической мордой, прошедшая с 1997 г. через 21 релиз и in daily use по сю пору.

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

У нас, правда, тоже есть свои ... Трурли :-)

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

Увы, ни один из известных языков этого цикла не поддерживает, кроме нового виртовского Оберон-07.

Пока описание этого языка ещё не доступно, и не факт, что цикл Дейкстры в нём останется...

Хм, а вот как цикл Дейкстры можно симитировать на Хаскелле:

func initial_state = while_do initial_state
  where
    while_do st | cond_1 st = while_do $ process_1 st
                | cond_2 st = while_do $ process_2 st
                  . . .
                | cond_n st = while_do $ process_n st
                | otherwise = process st

Конечно, есть некоторый оверхед, но ясно видно, что можно обойтись и без цикла Дейкстры почти без потери читабельности кода. Паттерн-матчинг и охранные условия рулят! :о)

Ответ на »сообщение 6058« (Илья Ермаков)
___________________________
Хотя я тут подумал - можно ответить и "в общем". Реально сложные циклы с break-ами возникают как раз в задачах автоматного толка
Говорите "в общем", а сами додумываете задачу :)
Присоединяюсь к предыдущему утверждению: без знания задачи нельзя сравнивать применяемые конструкции и вообще пути решения.
Сколько раз на круглом столе возникали вопросы типа "как выкрутится из..." и автор упорно не хотел слушать, "как туда не попадать".

Ответ на »сообщение 6054« (user.ru)
___________________________

Ответ на »сообщение 6051« (Илья Ермаков)
___________________________
И как будет выглядеть приведенный пример с использованием дейкстровского цикла?

Хотя я тут подумал - можно ответить и "в общем". Реально сложные циклы с break-ами возникают как раз в задачах автоматного толка: "перемалывание" потока событий/сиволов/данных/чего_угодно с переходами в разные состояния и с достижением в итоге конечного состояния (в которое можем приходить разными путями) - и вот это достижение конечного состояния и символизируют break-и в теле цикла.

Посему, если сама специфика задач такова, так и давайте идти "по шерсти" - использовать соответствующие методы. Вместо интуитивного ваяния распишем состояния, события, переходы - и построим автоматный цикл. Тот самый дейкстровский WHILE будет то, что доктор прописал... Да и без него обойдёмся:
LOOP
IF ... THEN
  ...
ELSIF ... THEN
  ...
ELSE
  EXIT
END
END

Ответ на »сообщение 6056« (Сергей Осколков)
___________________________

Ответ на »сообщение 6053« (Илья Ермаков)
___________________________
А вообще спасибо за обсуждение, напомню, то моя первая реплика на эту тему была не "вот так нельзя" или "вот так надо", а "а почему так?" Пояснения я получил.

В таком стиле и в таком русле мыслей, как у Вас, Сергей, вопрос break обсуждать вполне культурно, приятно и полезно :-)