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 имеет новый синтаксис: #<...>. И читатели, и писатели работают с этим синтаксисом.

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

Ответ на: комментарий от env

RMS это определение изобрёл, он его и приватизировал, всё в порядке.

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

Так почему же нельзя было туда встроить Guile ядром? :}

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

Кажись нашёл ответ

commit 448651caebe2809d6a966e4cf38d87b04628ee24
Author: Chris Hanson <org/chris-hanson/cph>
Date:   Sat Dec 13 17:04:26 1986 +0000

    Initial revision

A	v7/src/compiler/back/asmmac.scm
yoghurt ★★★★★ ()
Ответ на: комментарий от bodqhrohro_promo

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

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

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

а разве Git в 1986 году существовал? Или как они туда задним числом закоммитили

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

Тогда точно существовал rcs, и даже cvs уже наклевывался

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

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

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

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

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

Да банальный обход графа, например. Не, можно и без рекурсии на стеке накостылять, но с рекурсией проще.

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

Да элементарно задним числом коммитится, я так недавно историю правок за пару месяцев восстановил (до этого VCS не юзал, просто файлы бэкапил).

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

Кроссплатформенность не запилили, годный язык!

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

Мне скорее не нравится вот это форсированное выпячивание GNU/ в названии продукта. Это как если бы любой хостящийся на Github продукт добавлял в имя «Github».

Но ведь GNU — это же не просто репозиторий, это координированный проект по разработке софта, управляемый FSF.

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

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

Что, до GNU не было свободного софта под лицензиями MIT и BSD? Под последней вон целая ОС готовая уже была

Не было. Целая ОС (даже не одна, а две, NetBSD и FreeBSD) появилась примерно в 1991-1995 годах, тогда же, когда и GNU/Linux, даже позже.

Xenius ★★★★★ ()
Последнее исправление: Xenius (всего исправлений: 1)
Ответ на: комментарий от actionless

примеры из SICP не будут работать?

Я когда SICP читал, на guile всё делал и всё работало.

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

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

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

Раньше они еще оффтопик, например, поддерживали, да и Guile был в зачаточном состоянии.

buddhist ★★★★★ ()
Последнее исправление: buddhist (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Что, хотел сбыдлокодить очередной проприетарный хеллоуворлд, а лицензия не позволяет? Ай, ай, лицемеры из GNU плохие люди!

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

Да, прям сплю и вижу, как бы кому продать схемку для студентов. Анонимное чувырло снова поражает блестящим интеллектом.

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

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

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

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

Ну схемка может тебе и не нужна, а вот заюзать что-нибудь из Qt, который под GPL тебе бы неплохо было. Абсолютно все gpl-хейтеры просто расстроены тем, что нельзя писать зонды используя gpl-софт. Ненавидеть gpl не за что больше.

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

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

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

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

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

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

Абсолютно все gpl-хейтеры просто расстроены тем, что нельзя писать зонды используя gpl-софт. Ненавидеть gpl не за что больше.

Ну да. А невозможность в одной программе использовать части из samba и smbfs (GPL2 и GPL3 в одной программе нельзя)? А невозможность в программу на GPL скопировать кусок из Rosetta Code (GPL и GFDL несовместимы)? А необходимость либо держать сервер либо принудительно класть исходники в состав дистрибутива программы? Причём, если использовал общедоступную библиотеку под GPL, но не озаботился скачиванием исходников, а на момент окончания разработки, сервер где она была, уже не существует, то даже собственный код распространять не имеешь права.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А необходимость либо держать сервер либо принудительно класть исходники в состав дистрибутива программы?

А разве нельзя высылать исходники по требованию?

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

А разве нельзя высылать исходники по требованию?

Формулировка звучит так: «accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model». То есть должен письменно обязаться в течение не менее 3 лет предоставлять по требованию.

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

они вроде sbcl рекомендовали во вступлении к изданию, так что я не проверял на других

ну тогда и впрямь загадка

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

SICP
они вроде sbcl рекомендовали во вступлении к изданию

sbcl — это Steel Bank Common Lisp. Его ну никак не могли рекомендовать для SICP. Что-то путаете?

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

Да как минимум лицензионный, эту вашу жопаэль же в Этой Стране за лицензию не считают: оригинал не на рюссише, перевод не считается.

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

Да как минимум лицензионный, эту вашу жопаэль же в Этой Стране за лицензию не считают

А в чём проблема? Пакуешь в красивый диск, прилагаешь любую понравившуюся лицензию. В ней пишешь, что компоненты Программы могут распространяться потребителем на условиях GPL и даёшь ссылку на исходники. Сам RedHat так делает.

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

зато всякие тендерасты натурально спят и видят

а че, только переименовать, получить правильных сертификатов и профит

actionless ★★★★★ ()
Последнее исправление: actionless (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.