OberonCore

Вот такой, без деталей, код.
CONST N = 8;
L = 1;
R = 18;
PROCEDURE AnyThing;
BEGIN
END AnyThing;
PROCEDURE Srch ( i : INTEGER );
VAR k : INTEGER;
BEGIN
FOR k := L TO R DO
IF i < N THEN Srch (i+1)
ELSE AnyThing
END
END
END Srch;
PROCEDURE Main*;
BEGIN
Srch (0)
END Main;

Всё работает, когда N,L,R малы. Стоит поставить так как выше приведено (8, 1, 18),
то система зависает.
Рискну предположить, что-то типа исчерпания стека?

N вам ограничивает глубину поиска, а R — ширину. вы задали огромное рекурсивное ~(R^N)!-мерное поле поиска. простите, точную формулу сейчас не могу (написаная — чушь, конечно), но там совершенно астрономическое число получается. со стеком всё в порядке (глубина всего N), проблема именно в огромной области, которую всю надо перебрать. при нехватке стека среда просто покажет трап.

R^N или N^R?...
Да, Трап выкидывает. Но не всегда, чаще просто виснет, приходится принудительно завершать ББ и снова запускать.
В общем, я, конечно, понимал, что широкий и глубокий поиск.
Но смутило, что во FPC и PascalABC.NET работает.
Конечно, безмерно долго, но, по крайней мере, не виснет.

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

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

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