Вопрос: а есть ли скрипты или скриптоподобные системы, где реально, не перезагружая, можно менять код на лету, но при этом каждый скомпилированный узел AST пронумерован, и операции над живым кодом обязательно согласуются с текущим состоянием. В CGI, например, обновление на уровне новых http–запросов. В Erlang обновление на уровне новых вызовов функций. А вот как бы полностью контроль иметь, в том числе за теми функциями, что уже исполняются и ещё не завершились?
Однажды скомпилировав и получив пронумерованное AST, становится нельзя редактировать непронумерованный код, снова компилировать, получать совершенно иную нумерацию и пытаться активировать, потому что вот прямо в этот момент в обновляемых AST что–то происходит, и полный сброс портит всю задумку, которую я хочу.
А по задумке нужно работать с пронумерованным AST, и, если что–то добавляется, то сразу же и нумеруется. Если какие–то строки хочется удалить, они могут не удалиться сразу, потому что где–то в момент обновления они исполняются, и удаление строк будет отложено до момента, когда их исполнение везде прекратится.
Для чего это хочется? Типичные операции: запросы к БД, запросы по HTTP. Область применения: процессинг.
Проведение платежей теоретически может быть настраиваемо гибко. Есть продавцы типа Дом.ру, которые в разных регионах имеют разные идентификаторы service-id. Вот, чтоб простые люди на терминале не выбирали из нескольких одинаково выглядящих кнопок свой город, можно сделать одну кнопку, а дальше пусть бы процессинг по лицевому счёту анализировал, куда платёж послать. А ещё может понадобиться один платёж разбить на несколько, и успешность исходного платежа зависит от успешности платежей, но которые платёж был разбит. Далее, вот есть, допустим, российский Билайн и казахстанский Билайн. Их можно объединить, а потом различать по коду страны в телефонном номере, а ещё по валюте. При этом можно требовать, чтобы валюта совпадала, а можно конвертировать, если не совпадает (актуально на Байконуре, где платят в рублях, но территория Казахстан, поэтому могут и не рублями заплатить, или могут рублями за казахстанский Билайн заплатить). Получается несколько звеньев, в которых может происходить вариация. Что касается конвертации, то это может быть запрос в БД. Если данные устарели, запрос курса по HTTP. Это те самые узлы AST, которые нужно удалять не сразу, если где–то оно ещё исполняется. Скажем, сегодня мы конвертировали алтыны в рубли, а рубли в гривны, а завтра научились сразу в гривны запрос курса по HTTP делать. И если с новыми платежами всё понятно, они пойдут по новой схеме, то старые могут подвиснуть, если запрос курса накрылся или что–то в этом роде. Желательно вот поэтому полный контроль иметь над происходящим.
