Идиоматический способ определить несколько бэкэндов в Common Lisp?

Чтобы дополнить другие ответы, для этого варианта использования есть две библиотеки. Оба вдохновлены метамоделью Магритта, вы должны проверить это из.

Одним из них является descriptions, который позволяет вам определять различные "представления" объекта. Он использует не CLOS, а Sheeple, основанную на прототипе объектную систему для CL. Более ранний подход — MAO, основанный на CLOS. Он добавляет 3 дополнительных слота к стандартному объекту слота. метка-атрибута, функция-атрибута и значение-атрибута. Функция в функции-атрибуте a преобразует значение слота в окончательное представление, если функция равна нулю, значение в значении-атрибуте используется как есть. А метка — это описание значения, похожее на метки в html5-формах.

Я бы реализовал бэкенды как отдельные классы, вместо того, чтобы передавать ключевое слово, так как это позволило бы мне привязывать различные состояния к объекту и сохранять их.

Я бы, вероятно, (иначе) использовал общий дизайн функций, на который вы ссылались.

Common Lisp Interface Manager и несколько бэкендов

Примером уровня пользовательского интерфейса в CLOS, поддерживающего несколько бэкендов, является CLIM, Common Lisp Interface Manager. Вы можете изучить дизайн его программного обеспечения. См. ссылки ниже. См., например, протоколы вокруг таких классов, как port (подключение к сервису отображения), medium (где происходит рисование, класс протокола, соответствующий в состояние вывода для какого-либо листа), лист (поверхность для рисования и ввода, примерно похожая на иерархические окна), прививать (лист, который заменяет хост-окно), ... В приложении открывается порт (например, для определенной оконной системы, такой как X11/Motif), а остальная часть приложения должна работать в основном без изменений. Затем архитектура CLIM сопоставляет все свои службы с определенной серверной частью CLIM, которая предоставляет интерфейс для X11/Motif (или любого другого порта, который вы будете использовать).

Например, функция draw-line будет рисовать на листах, потоках и носителях. Затем общая функция medium-draw-line* реализует различные версии рисования линий для одного или нескольких подклассов средних.

В целом это было не очень успешным, потому что уровень переносимого пользовательского интерфейса усложняет и требует много работы для разработки и поддержки. В середине 90-х рынок приложений Lisp был небольшим (см. AI Winter), CLIM был недостаточно хорош, а реализация была закрытой или проприетарной. Позже была разработана бесплатная реализация с открытым исходным кодом под названием McCLIM, которая создала работающее программное обеспечение, но в конечном итоге разработчики/пользователи потеряли интерес.

Немного истории

В прежние времена Symbolics разработала систему пользовательского интерфейса под названием «Динамические окна». Он был выпущен в 1986 году. Он работал в операционной системе Symbolics и мог использовать собственную комбинацию ОС / аппаратного обеспечения и X11. Примерно с 1988 года была разработана портативная версия на основе CLOS. Первые доступные версии (особенно версия 1.0 в 1991 году) были доступны на нескольких платформах: Genera, X11, Mac и Windows. Позже была разработана новая версия (версия 2.0), которая снова работала на различных системах, но включала сложный объектно-ориентированный слой, который предоставлял более явный внутренний слой под названием Silica. Этот внутренний слой поддерживал не только такие вещи, как портативное рисование, но и части абстрактной оконной системы. Более амбициозные части, такие как поддержка адаптации внешнего вида (ползунки, стили окон, полосы прокрутки, меню, элементы диалога и т. д.), не были полностью проработаны, но, по крайней мере, были доступны в версии первого поколения.

Указатели

Экскурсия по CLIM, диспетчеру интерфейса Common Lisp (PDF)

Кремнезем: Реализация отражения в кремнеземе (PDF)

Спецификация (включая Silica): Common Lisp Interface Manager 2.0 Specification

Под «бэкендом» ты подразумеваешь фронтенд, верно? Например, часть, с которой взаимодействует пользователь, а не часть, которая обрабатывает логику приложения?

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

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

(defclass backend () ())
(defgeneric do-something (backend x y))

(defclass fast-backend (backend) ())
(defmethod do-something ((backend fast-backend) x y)
  (format t "Using fast backend with arguments ~a, ~a.~%" x y))

(defclass low-mem-backend (backend) ())
(defmethod do-something ((backend low-mem-backend) x y)
  (format t "Using memory efficient backend with arguments ~a, ~a.~%" x y))

(defun main (x y)
  (let ((backends (list (make-instance 'fast-backend)
                        (make-instance 'low-mem-backend))))
    (dolist (b backends)
      (do-something b x y))))

Еще одно изменение: если вам нужно использовать такие функции, как mapcar, вы можете захотеть иметь глобальную переменную, содержащую текущий бэкенд. Затем определите функцию-оболочку, которая использует метод global.

(defparameter *backend* (make-instance 'fast-backend))
(defun foobar (x y)
  (do-something *backend* x y))

(defun main (x y)
  (foobar x y)
  (let ((*backend* (make-instance 'low-mem-backend)))
    (foobar x y))
  (foobar x y))