Подключение .NET к Common Lisp - PullRequest
Новая
       16

Подключение .NET к Common Lisp

8 голосов
/ 22 апреля 2010

У меня есть довольно вовлеченный модуль LispWorks Common Lisp, который находится над некоторыми модулями .NET через RDNZL.

Мне пришло в голову, что мне нужно предоставить некоторые его функции другим приложениям .NET, и яЯ не уверен, лучший (самый короткий) способ приблизиться к этому без переписывания модуля в C #.Я знаю, что есть несколько реализаций CLR Lisp, но большинство из них кажутся незавершенными или неполными, и есть много вещей, которые не могут быть тривиально переписаны на схеме.NET -> Common Lisp)?Могу ли я использовать RDNZL для доставки библиотеки DLL, которая принимает объекты .NET?

Я редактирую это, чтобы включить некоторые параметры, о которых большинство пользователей, заинтересованных в Лиспе, вероятно, узнают, находятся ли они в Windows,и почему они не совсем соответствуют вышеуказанным требованиям (или как, как и ваши пользователи, я не смог адекватно передать свои требования:).

  • IronScheme - Хороший, быстрый, поддерживаемый и быстрый, но этоне общий Лисп
  • ClojureCLR - Не общий Лисп;Бета, мне требуется ~ 4 сек для запуска (приемлемо для долго работающих приложений, а не для вещей, которые требуют новых экземпляров, а затем несколько десятков вызовов)
  • LSharp - Not Common Lisp, не поддерживается
  • RDNZL - Позволяет регистрировать делегатов обратного вызова CL с кодом .NET, но начинать нужно с CL, нет относительно простого способа (который я до сих пор мог выяснить) передавать объекты .NET в "C"DLL ", созданная выбранной вами реализацией Common Lisp.
  • Yarr - построен на основе LSharp (включает defmacro и некоторые другие необходимые компоненты).Выглядит неокрепшимся в течение некоторого времени, но может быть лучшим вариантом на данный момент.

Ответы [ 2 ]

5 голосов
/ 23 апреля 2010

"Я понял, что мне нужно разоблачить некоторые его функции для некоторых другие приложения .NET "

Следующее не совсем то, о чем вы просите, но если вы хотите немного подумать, я думаю, что, возможно, использовать обмен сообщениями будет проще всего (это полностью основано на приведенном выше утверждении). Что-то вроде ZeroMQ , в котором есть привязки как для Common Lisp, так и для .Net. Тогда вопрос будет не в том, как переписать модуль, чтобы сделать его совместимым с .Net, а в том, как интегрировать обмен сообщениями в модуль для независимого приложения .Net, которое будет его использовать. Обе стороны разговора должны будут договориться о формате сообщений, но, на мой взгляд, это проще, чем маршрут, который вы рассматриваете в своем посте.

Если вам нужно создать более одного приложения, возможно, вам подойдет архитектура pub / sub.

0 голосов
/ 23 апреля 2010

Возможно, вы найдете интересный LSharp LSharp Существует также Железная схема Существует также Xronos , который утверждает, что является диалектом Лисп.

Я бы потратил немного времени на изучение того, насколько сложно было бы перенести ваш код на F # с учетом ограничений и различий, которые имеет язык по сравнению с Лиспом.В Лиспе, конечно, есть довольно много конструкций, которые мне было бы сложно элегантно вдавить в F #.

...