Илья Ермаков писал(а):
Я имею в виду, что если в стандарте языка будет указано, что "компилятор языка обязан трансформировать статически обнаруженный концевой рекурсивный вызов", то я смогу писать алгоритм, полагаясь на этот факт (например, программировать "бесконечно" работающий КА); а иначе на каком-нибудь компиляторе получу вылет за стек после первой же тысячи-другой переходов автомата
Не думаю, что это хорошая идея... Проще/правильнее сделать работу на основе сообщений. В противном случае, единожды скомпилированный код будет работать по одной и той же схеме, что не очень гибко... Представьте, что в том же QiuckSort вместо концевых вызовов отсылаются соответствующие сообщения. По мере возможности исполнитель обрабатывает эти сообщения... параллельно (каждое сообщение определяет свою часть массива, и эти части не пересекаются, это очень удобно для параллельной обработки). Сообщения можно упорядочить, по "уровню вложенности" (чем больше "уровень вложенности", тем позже обрабатывается/ниже приоритет сообщения).
А если делать переходы, то точки перехода нужно оставить программируемыми, типа:
Код:
jmp [jump_address]
Тогда адрес перехода можно будет менять в зависимости от условий/результата выполнения данного перехода или... извне.
Илья Ермаков писал(а):
Ну, jump компилятор пусть генерирует, если процедуры без параметров (например, прыгаем между вложенными процедурами), а в противном случае пусть обычный call, но сначала разгружает стек уже оконченной вызывающей процедуры.
Разгрузив стек до перехода, мы утрачиваем контекст исполнения (фактические параметры, локальные переменные, результаты...). Сообщения всё же лучше... Их можно перенаправлять, перехватывать, игнорировать, откладывать, переставлять в каком-то заданном порядке, обобщать, делать пакетную обработку и т.п...
Илья Ермаков писал(а):
Да, да, есть ещё вопрос, как с VAR-параметрами - можно запретить.
Простым запрещением эту задачу не решить, IMHO. Нужен полноценный аппарат разрешения конфликтов.
Илья Ермаков писал(а):
Вообще, этот механизм может решить все проблемы, когда одномерное структурное программирование "жмёт". Вместо goto - концевая передача управления от процедуры к процедуре.
Может быть, стоит не делать оптимизацию концевого вызова, а ввести отд. оператор, который обозначает совершение такого вызова с завершением вызывающей процедуры.
Собственно, что-то всё равно нужно... либо адрес возврата, либо адрес перехода, альтернатива им... halt/передача управления системе, но это не слишком разумно.
Илья Ермаков писал(а):
Нюансов много, но простой вариант найти можно, а овчинка выделки стоит. Оптимизация рекурсий, автоматность, строгий вариант goto для алгоритмов управляющего характера - всё одним средством.
... сообщением...