Страницы

Поиск по вопросам

Показаны сообщения с ярлыком scheme. Показать все сообщения
Показаны сообщения с ярлыком scheme. Показать все сообщения

понедельник, 6 января 2020 г.

Интерпретатор Scheme для линукса

#lisp #scheme


Посоветуйте интерпретатор Scheme для линукса. Хочу, чтобы он был с REPL, с возможностью
вернуться стрелкой вверх к предыдущему выражению и отредактировать в нем любое место,
а не только последнюю строку. Чтобы скрипты .scm можно было запускать из консоли как
обычные программы и получать на экране ответ. Предложений много, не знаю, что выбрать.
    


Ответы

Ответ 1



Для Linux и встраивания, сейчас уже однозначно - Guile. С целью писать в продакшен для платформ, в т.ч. мобильных - Gambit. У Chicken комьюнити а-ля AUR, соответственно - толковая организация модулей и хорошая поддержка. Когда нет возможности использовать EMACS, и с целью обучения в качественной среде, подходит Racket. Практичный инструмент для всего, что можно назвать сценариями - SCSH.

Ответ 2



Geiser в Emacs поддерживает Guile, Racket и CHICKEN Scheme (из @haziz ответа на связанный вопрос).

Ответ 3



Хорошая альтернатива - Chez Scheme. У него есть встроенный редактор s-выражений (expedit), быстрая VM и дополнение названий симболов.

вторник, 26 ноября 2019 г.

Чего не может C# в отличие от Scheme для работы с ИИ? [закрыт]


Почему для работ в области искусственного интеллекта часто выбирают какой-нибуд
из диалектов Лиспа или Пролог, что в них такого, чего нельзя сделать на C#? Интересую
именно сравнение возможностей (что можно сделать в одном языке программирования, но невозможно или проблематично в другом) языка, а не готовых алгоритмов/методов или их количества.

upd: Нашел проект IronScheme, зеркало Github


  IronScheme implements over 99% of the R6RS specification and specified behavior.


пример работы из C#, документация
    


Ответы

Ответ 1



Вполне законно вопрос поставить шире: сравнение возможностей процедурного, функциональног и логического программирования. Вопрос очень широкий и требует как минимум хорошей академической статьи. В принципе, возможности большинства языков всех этих групп достаточно близки. Вопро только в простоте и легкости реализации тех или иных задач. Думаю, все, что можно сделат на Лиспе или Прологе, вполне возможно реализовать и на C#. Только там, где на этих языках та или иная операция будет занимать пару строчек, на процедурном языке может занять пару десятков.

Ответ 2



Scheme - изящный и простой язык, к тому-же близость синтаксиса к соответствующем AST Tree позволяет программисту интуитивно генерировать необходимые языки с помощь макросов. Вообще, для Scheme естественно, что код - это данные. Это полезно для разработчиков всевозможного матана, в тч специфичного для AI (обработка и генерация графов - сильное место любого Lisp), но также и интернет-магазинов.... Есть в Scheme принципиально отсутствующие в C# сущности, например: продолжения (Continuations) как объекты первого класса. Это фактически значит, что состояние всей программы можно сохранять и восстанавливать на уровне языка. Scheme - мультипарадигменный язык, его философия не навязывает ООП, равно как чисто-функционально или реактивное программирование. Экосистема Scheme поддерживает развитые средства для любых, в т.ч. и эксперементальных методик. Хотя не существует единого репозитария Scheme-кода и стандарта модульности, зат развита теория и добрая традиция переиспользования функций, построенных (возможно) в разных стилях. Есть и база качественного кода на Scheme. Скажем, их даже несколько. REPL - традиционный для LISP способ коммуникации с интерпретатором, "выращивания окружений. Изменения вносятся в непрерывно работающую программу - подобным образом математик работают с Maxima и её аналогами. Для некоторых современных языков, того-же С#, совершенно необходимо специальное IDE. Однако есть и мнение, что IDE в целом усложняет процесс разработки, во всяком случае - итеративный процесс разработки очевидно помогает разгрузить оперативную память программиста. Существуют компиляторы и интерпретаторы Scheme для любой архитектуры - ARM, Webkit/ECMAScript .NET, Java... Благодаря простоте, Scheme - в мире, один из самых портированых языков. С недавних пор, он выбран стандартным языком расширения GNU, и на этой платформе построен дистрибутив GUIX с демоном инициализации Shepherd (замена init и systemd).

Ответ 3



Есть множество языков программирования. Вот для алгоритмов или ИИ нужна спец. подготовка А специалистов таких не много. Теперь выберите из этого числа людей тех, кто на профессионально уровне знает тот же С#. Вот и получается что тем, кто занимается ИИ, проще написать (())О() в пару строк - и все готово. Тут тебе и строгой типизации нет, и ООП учить (почти) не надо. А вообще была бы возможность, выучил бы F#. У меня даже книга есть по нем. Но язык мне действительно показался сложноватым.

Ответ 4



Наверное, то, что сама идеология Лисп, в отличие от идеологии С#, более подходи для написания самомодифицирующегося кода - кода, анализирующего и модифицирующего самого себя. То есть Лисп свой собственный исходник может обрабатывать как данные.

среда, 17 октября 2018 г.

Кроссплатформенная разработка на Scheme

Начал использовать lambdanative, основанный на Gambit Scheme, всё компилируется и работает, однако не могу понять, как в Gambit C полноценно отлаживать приложение в стиле итеративной lisp разработки, так как под него geiser в EMACS настроить не удалось.
Суть вопроса - как сделать, чтобы я видел запущенное приложение (так же, как оно выглядит, скомпилированным в эмуляторе Android SDK и iOS) и мог добавлять в него функциональность через REPL, в реальном времени?
Возможно, есть лучший путь - ведь тот-же geiser хорошо интегрирован с Chicken Scheme (более популярный чем Gambit) и guile (стандартный язык GNU) - может быть полезнее портировать функциональность lambdanative на один из них, чтобы получить комфортную среду... Но это и оверинжиниринг, ведь именно Gambit-C в данном случае уже хорошо работает с платформами, т.е. вопрос всё-таки в том, как выглядит правильный цикл работы с Gambit.


Ответ

Добавлю в виде ответа. Вопрос решён, в комментарии от 3 окт '15 есть ссылка на мой тред с авторами, в документации появился раздел Debugging и пример конфигурации: https://github.com/part-cw/lambdanative/wiki/Debugging

вторник, 2 октября 2018 г.

Чего не может C# в отличие от Scheme для работы с ИИ? [закрыт]

Почему для работ в области искусственного интеллекта часто выбирают какой-нибудь из диалектов Лиспа или Пролог, что в них такого, чего нельзя сделать на C#? Интересуют именно сравнение возможностей (что можно сделать в одном языке программирования, но невозможно или проблематично в другом) языка, а не готовых алгоритмов/методов или их количества.
upd: Нашел проект IronScheme, зеркало Github
IronScheme implements over 99% of the R6RS specification and specified behavior.
пример работы из C#, документация


Ответ

Вполне законно вопрос поставить шире: сравнение возможностей процедурного, функционального и логического программирования. Вопрос очень широкий и требует как минимум хорошей академической статьи. В принципе, возможности большинства языков всех этих групп достаточно близки. Вопрос только в простоте и легкости реализации тех или иных задач. Думаю, все, что можно сделать на Лиспе или Прологе, вполне возможно реализовать и на C#. Только там, где на этих языках та или иная операция будет занимать пару строчек, на процедурном языке может занять пару десятков.

понедельник, 1 октября 2018 г.

Чего не может C# в отличие от Scheme для работы с ИИ? [закрыт]

Почему для работ в области искусственного интеллекта часто выбирают какой-нибудь из диалектов Лиспа или Пролог, что в них такого, чего нельзя сделать на C#? Интересуют именно сравнение возможностей (что можно сделать в одном языке программирования, но невозможно или проблематично в другом) языка, а не готовых алгоритмов/методов или их количества.
upd: Нашел проект IronScheme, зеркало Github
IronScheme implements over 99% of the R6RS specification and specified behavior.
пример работы из C#, документация


Ответ

Вполне законно вопрос поставить шире: сравнение возможностей процедурного, функционального и логического программирования. Вопрос очень широкий и требует как минимум хорошей академической статьи. В принципе, возможности большинства языков всех этих групп достаточно близки. Вопрос только в простоте и легкости реализации тех или иных задач. Думаю, все, что можно сделать на Лиспе или Прологе, вполне возможно реализовать и на C#. Только там, где на этих языках та или иная операция будет занимать пару строчек, на процедурном языке может занять пару десятков.