Как передать код программы?

Question

Недавно я изучал Лисп (Scheme, Racket и Clojure в разной степени) и прочитал соответствующую литературу о знаменитом разработчике Playstation Naughty Dog.

This Gamasutra article упоминает, что их потоковый движок фактически передает в игровом коде в дополнение к игровым данным. Теперь у них есть диалект Лиспа под названием GOAL, который они используют широко. Я знаю «код как данные» Лиспа, хотя мне еще предстоит полностью понять эту концепцию. Итак, мне было интересно, является ли способность передавать код в качестве своего кода, являющегося данными Lisp или скомпилированным машинным кодом, а не общим шаблоном проектирования, который может использоваться на многих языках?

Может кто-нибудь указать мне на литературу по этой теме?

Бонус: Может ли кто-нибудь указать мне на литературу по компиляторам с длительным прослушиванием, как указано в Wikipedia article?

Answer 1

«Слушатель» в Лисп говорит REPL (Read Eval Print Loop). Слушатели обычно предоставляют несколько сервисов, таких как встроенный отладчик, истории команд, интерпретаторы команд и т. Д. Во многих случаях Listener запускается внутри используемого Lisp. В некоторых случаях весь код, набранный для REPL/Listener, скомпилирован перед выполнением (примеры - Clozure CL, SBCL). Если это не так, код может быть скомпилирован по требованию (см. Функции COMPILE или COMPILE-FILE в Common Lisp).

Здесь я бы предположил, что среда разработки была реализована в Allegro Common Lisp, а среда исполнения работает на Playstation. Среда разработки обеспечивает интерфейс для общения со средой выполнения и позволяет скомпилировать код и загрузить его во время выполнения. Я бы предположил, что компилятор не работает на Playstation, а внутри среды разработки. Затем Listener также предоставляет функциональные возможности для просмотра состояния запущенного приложения на Playstation, включая таблицу символов. Таким образом, один соединяет среду разработки с запущенным приложением Playstation и может взаимодействовать с ним, включая изменение данных и кода.

Поскольку типизация Lisps может загружать как исходный, так и скомпилированный код во время выполнения, код «потоковой передачи» не так уж трудный. Это просто означает, что один загружает код (возможно, в фоновом режиме), когда игрок перемещается в игре. Если код организован определенным образом, он также может быть собран из мусора, когда он больше не нужен. Например, если «комната» в игре является объектом, а комната указывает на различные функции по имени, функции могут быть автоматически загружены по требованию, если игрок находится в комнате. Если игрок покидает комнату, код может быть автоматически или полуавтоматически разгружен. В типичном Lisp сборщик мусора собирал код без ссылок. В игре, которая не может быть задачей ГК, но какого-то другого более «ручного» процесса. Это будет функциональностью среды выполнения GOAL. Сравните это с запасом JVM, который не мог мусор собирать разгруженный код (AFAIK).

Answer 2

Их потоковый движок более или менее реплицирует то, что загружает DLL (Windows), SO (Linux) или Dylib на более общие ОС, и не все это интересно за пределами того факта, что они внедрили его сами. Он не имеет ничего общего с языком, который они используют. Что касается долгосрочных компиляторов для прослушивания, это первый раз, когда я услышал редактирование и продолжаю приписываться компилятору, это обычно функция отладчика.

Answer 3

Я сброшенные о с такого рода вещи очень немного в Common Lisp, и то, что ваш код может выглядеть так:

on connection: 
    read Lisp form 
    eval Lisp form 
    close connection 

Это не массово отличается концептуально от, скажем, слизь.

Также обратите внимание, что из-за природы Common Lisp код с возможностью «горячей замены» не является большим.