LINUX.ORG.RU

MIT/GNU Scheme 10.1

 , , ,


2

3

MIT/GNU Scheme — это реализация языка программирования Scheme, предоставляющая интерпретатор, компилятор, отладчик исходного кода, встроенный Emacs-образный редактор и большую библиотеку времени выполнения. MIT/GNU Scheme заточен под программирование больших приложений с быстрым циклом разработки.

Изменения:

  • Сборки для Windows больше не распространяются, поскольку существовавшие 32-разрядные сборки малопригодны для современных систем, а для достижения работоспособности 64-разрядной нужны немалые усилия, в которых никто из текущих сопроводителей не заинтересован.
  • Для macOS теперь выпускаются только 64-разрядные сборки, поскольку в применяемом в последних выпусках инструментарии поддержка 32-разрядной сборки объявлена устаревшей.
  • Переносимая версия для C не включена в этот выпуск, поскольку её не удалось вовремя починить.
  • На следующий выпуск запланировано кучу мелких улучшений; первоочерёдными задачами этого выпуска являются нововведения.

Важные нововведения:

  • Почти полностью поддерживается R7RS (Семикратно Пересмотренный Отчёт по Алгоритмическому Языку Scheme), кроме:
    • автоподгрузки библиотек, которая появится в следующем выпуске;
    • многозначных возвратов, с которых есть прок лишь в ограниченных условиях; для исправления этого нужна сильная переработка компилятора, которая вряд ли когда-либо будет произведена.
    Обратите внимание на новую возможность R7RS — параметры, предоставляющие переносимый способ динамического связывания. С этого выпуска использование fluid-set объявлено устаревшим, и будет полностью удалено в будущем.

    Учтите также, что поведение REPL (цикл чтения-выполнения-вывода) не изменилось. То же самое касается загрузчика и компилятора, поскольку они автоматически определяют наличие R7RS-кода в файле и соответствующим образом это обрабатывают. Эти изменения позволяют и существующему коду работать, и новому писаться.

  • Поддержка Юникода:
    • поддержка NFC- и NFD-нормализации; большинство строк теперь в NFC;
    • поддержка конвертации между строками и байтовыми векторами UTF-{8,16,32};
    • символы, читатель, писатель и текстовые порты теперь поддерживают Юникод;
    • таблицы символов теперь поддерживают Юникод и занимают значительно меньше места благодаря внедрению списков инверсии;
    • новый соответствовальщик регулярным выражениям regsexp поддерживает Юникод;
    • старые соответствовальщики и rexpне поддерживают;
    • Edwinтоже.
  • Добавлен интерфейс внешних функций для динамической подгрузки C-библиотек и взаимодействия с ними из Scheme. Этот интерфейс заменил собой много специализированных интерфейсов к различным библиотекам, которые теперь представлены в виде плагинов.
  • Реализована виртуальная машина, svm, которая поддерживается в качестве нативной цели сборки. Хоть она и намного медленнее нативного кода, но работает на любой архитектуре. В этом выпуске предоставлена 64-разрядная версия; 32-разрядной нет, но она может быть собрана при необходимости.

Ещё изменения:

  • начальная поддержка SMP;
  • уведомления сборщика мусора;
  • события нитей;
  • многие другие мелкие нововведения и исправления.

Несовместимые изменения:

  • Большинство строк теперь иммутабельны! Почти все способы создания строк генерируют иммутабельные строки, кроме make-string и string-copy. Иммутабельность привносит множество новых возможностей, в первую очередь возможность использования компактных представлений, см. подробности в руководстве.
  • Процедура hash изменена для совместимости с SRFI 69. Перед этим она была похожа на object-hash, которая теперь должна использоваться вместо неё.
  • Процедуры vector-8b, использовавшиеся для работы со строками как с векторами байтов, объявлены устаревшими. Используйте вместо них непосредственно векторы байтов.
  • Процедуры для работы с URI больше не принимают в качестве аргументов строки. Конвертируйте строки в URI с помощью ->uri при их использовании.
  • Удалена поддержка старых форм кодирования в Юникод. Используйте вместо них конвертеры в векторы байтов, если это вообще нужно, поскольку для многих задач теперь отпала необходимость особым образом работать с Юникодом.

Экспериментальные новые возможности:

  • Тип URI имеет новый синтаксис: #<...>. И читатели, и писатели работают с этим синтаксисом.

>>> Подробности



Проверено: jollheef ()
Последнее исправление: bodqhrohro_promo (всего исправлений: 2)

Смотрю я на все эти лиспы, и гложет меня вопрос. А может ли один и тот же разработчик одинаково хорошо реализовывать задачи на императивных и функциональных ЯП, или это заточенность мозгов? Я просто до функциональщины на реальных задачах так и не добрался к сожалению...

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

Карандаш точить

Нужно не спеша,

Чтобы кончик не сломался

У КАРАНДАША-А-А-А-А!

Только при чём тут мозги? в карандаше их нет, хоть многие им и думают. Мозги не перетачивают.

bodqhrohro_promo
() автор топика
Ответ на: комментарий от hobbit

Ну и эта, функци-Анальщина на деле куда идеологически ближе к императивщине, чем кажется; без рекурсии и указателей на колбэки ты и в императивщине далеко не уедешь. Вон даже жабка, оплот императивщины головного мозга, сдалась и ввела сахарочек для лямбд (на деле там под капотом интерфейс с одним методом, потому что голыми переменными да функциями жабка оперировать не умеет, так-то). То же самое мутабельности и монадок касается; если у тебя из функции внешнее состояние шатается, то при попытке покрытия оной автотестами непременно случится пригорание нижних отделов спины, и ФП тут, опять же, ни при чём, хотя казалось бы. Ну а в радикальщину вдаваться, как unclechu — это то же, что на ассемблере всё писать (куды уж императивнее?!), но с другой стороны.

bodqhrohro_promo
() автор топика
Ответ на: комментарий от bodqhrohro_promo

без рекурсии и указателей на колбэки ты и в императивщине далеко не уедешь.

это где это без рекурсии не уедешь, где вообще рекурсия, кроме учебных примеров применяется

Harald ★★★★★
()
Ответ на: комментарий от Harald

а, про императивщину пусть бодхрохро рассказывает, у меня оно как правило разматывается в std::stack<> и иже с ним :)

yoghurt ★★★★★
()
Ответ на: комментарий от yoghurt

Ну вот и разматывай, некоторые и вместо ООП упорно размазывают в функции с аргументом-объектом, потому что им ТАК ПРОЩЕ, и переменные одной буквой называют, ШОБ МНОГО НИПИЧОТОТЬ.

bodqhrohro_promo
() автор топика
Ответ на: комментарий от bodqhrohro_promo

Ну вот и разматывай

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

некоторые и вместо ООП упорно размазывают в функции с аргументом-объектом, потому что им ТАК ПРОЩЕ

Порой так даже правильней. Зачем объекту засорять интерфейс, если можно обойтись слабосвязной функцией?

yoghurt ★★★★★
()
Ответ на: комментарий от bodqhrohro_promo

std::stack - использует хип, размер которой практически неограничен. При рекурсивном вызове функции используется стек треда/процесса, размер которого зависит от настроек ОС, но как правило достаточно мал (несколько мегабайт).

anonymous
()
Ответ на: комментарий от anonymous

При рекурсивном вызове функции используется стек треда/процесса, размер которого зависит от настроек ОС, но как правило достаточно мал (несколько мегабайт).

ulimit -s unlimited, также можно выставить из самой программы

Leron ★★
()
Ответ на: комментарий от Harald

где вообще рекурсия, кроме учебных примеров применяется

Пробежаться по файловой системе, например?

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Или, вот ещё пример, разобрать JSON.

anonymous
()
Ответ на: комментарий от Harald

где вообще рекурсия, кроме учебных примеров применяется

Отрисовка элементов графического интерфейса.

monk ★★★★★
()
Ответ на: комментарий от Harald

это где это без рекурсии не уедешь, где вообще рекурсия, кроме учебных примеров применяется

Есть успешные, то есть практически важные языки ФП. Например, XSLT (специализированный язык для обработки XML), Erlang (предназначен для асинхронной распределённой обработки), R. R предназначен в основном для математической статистики, поэтому в нём широко применяются операции с множествами, которые удобно представить в ФП. Он допускает и процедурный стиль программирования, но настоятельно рекомендуется использовать ФП. Так, при моём сравнении рекурсивной и итеративной реализации некоторой операции с массивом оказалось, что рекурсивная во много раз быстрее. Это - типично для R, а не вообще для ФП.

Для чего нужен обсуждаемый язык - я не понял, но подозреваю, что ни для чего. Это подозрение связано с

Сборки для Windows больше не распространяются, поскольку существовавшие 32-разрядные сборки малопригодны для современных систем, а для достижения работоспособности 64-разрядной нужны немалые усилия, в которых никто из текущих сопроводителей не заинтересован.

Partisan ★★★★
()
Ответ на: комментарий от hobbit

Нет, императивные языки не настолько хороши, как функциональные.

Miguel ★★★★★
()
Ответ на: комментарий от hobbit

А может ли один и тот же разработчик одинаково хорошо реализовывать задачи на императивных и функциональных ЯП, или это заточенность мозгов?

А может ли один и тот же плотник одинаково хорошо орудовать и пилой, и топором?

anonymous
()
Ответ на: комментарий от anonymous

Пила и топор всё-таки имеют куда более чёткую специализацию. (Хотя опытный человек в некоторых случаях сможет рубануть топором так, что пила не понадобится.)

Ты готов обрисовать круг задач, для которых совершенно точно надо браться за функциональный ЯП, даже если вся остальная система написана на Java или C++?

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Пила и топор всё-таки имеют куда более чёткую специализацию.

Конечно, метафора (как и все метафоры, в общем-то) не идеальна. Тем не менее в ответ на твой вопрос

А может ли один и тот же разработчик одинаково хорошо реализовывать задачи на императивных и функциональных ЯП, или это заточенность мозгов?

могу сказать, только, что я не вижу никаких препятствий для разработчика научиться одинаково хорошо пользоваться и функциональным, и императивным подходами. И, как тут правильно кто-то сказал, мозги — не карандаш, нет никакой «заточенности мозгов», всему можно научиться.

Ты готов обрисовать круг задач, для которых совершенно точно надо браться за функциональный ЯП,

Это уже другой вопрос, не «есть ли такие разработчики», а «есть ли такие задачи». Нет, вот прям щас не готов. Хотя верю, что есть задачи, которые лучше ложатся на тот или другой подходы.

даже если вся остальная система написана на Java или C++?

Скорее нет, чем да. Но тут уже надо очень пристально рассматривать конкретную ситуацию.

Смотрю я на все эти лиспы

И да, наверное ты уже это слышал, но я ещё раз скажу, на всякий случай. Тот же общелисп — язык мультипарадигменный. На нём без проблем можно писать в императивном стиле. И на схеме тоже можно, хотя она и будет немного подталкивать к функциональщине.

anonymous
()
Ответ на: комментарий от hobbit

Можно писать основной код на C и забиндить к нему лисп для конфигов, если это катит, то вполне можно совмещать.

slapin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.