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)
Ответ на: комментарий от monk

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

а это вообще хорошая идея распространять продукт зависящей от бинарной сборки какой-то либы исходники от которой потерялись?

я бы перед распространением озаботился портированием на версию либы, для которой исходники еще можно найти.

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

Не нравится русский язык — дуй спикать фром ё харт куда-нибудь на HackerNews.

Тебя следует истребить как раз из любви к русскому языку. Так что дуй тявкать в свою будку на твоём родном собачьем.

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

А кто высылать будет, если автор уже тоже тю-тю?

Но если автор уже тю-тю, то лицензионные претензии, вероятно, уже не представляют для него проблемы.

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

во вступлении к изданию, а не к оригинальной книге

Что значит «издание»? Второе издание — это «оригинальная книга» или нет? А первое издание?

В любом случае, рекомендовать SBCL для работы с SICP вряд ли возможно, поскольку в SICP используется диалект лиспа Scheme, а SBCL — это Common Lisp. Весьма разные языки.

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

Можно подумать, GPL спасёт от тендерастов в этой стране.

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

Ничего там не было про конкретную реализацию, а про Racket и быть не могло, потому что он отличается от стандартной схемы.

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

про Racket и быть не могло, потому что он отличается от стандартной схемы.

Как раз для Racket, справедливости ради, и могло. Потому что у Racket есть, среди прочих, специально заточенный режим совместимости с SICP.

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

SCCS скорее всего, так как rcs как систему для деревьев исходников никто не воспринимал (очень неудобно), а CVS еще не было. Но они очень схожи (история пофайловая).

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

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

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

На кой ляд? в той же жабке библиотеки зачастую именно так и распространяются: закинул jar-ку в проект, подключаешь и юзаешь — и какое тебе дело, где там сырцы лежат и выходят ли апдейты... Десятки лет так может использоваться, обратная совместимость жыж.

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

а это вообще хорошая идея распространять продукт зависящей от бинарной сборки какой-то либы исходники от которой потерялись?

Ну вот пример. Есть у меня сервер на ASPLinux 7.2. Там есть пара самописных утилиток, использующих Readline. И сейчас владелец этого сервера формально не имеет права передать этот сервер кому-либо ещё.

Разве что сначала я должен эти утилиты портировать на современную версию линукса. Ну или пересобрать там системный Readline из исходников, если получится (патчей от дистрибутора ведь нет).

Поэтому и получается, что как только начинаешь использовать что-либо GPL, приходится выкачивать всё дерево зависимостей c GPL лицензиями и не забывать обновлять их, когда обновляется система.

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

Совсем бояры перепил, свинью от собаки отличить не можешь? Ану кыш отсюда, неадекватное гоможивотное, и пока не протрезвеешь — на ЛОР не возвращайся.

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

Ну или пересобрать там системный Readline из исходников, если получится (патчей от дистрибутора ведь нет).

так то дистрибутор обязан предоставить код (в данном случае патчи) по требованию

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

я перепроверил, в sicp такого не было, но делал 100% на racket-е (воспоминания прояснились со временем :-))

может, после htdp отложилось что scheme == racket и поэтому даже не думал, что выбирать для «прохождения»

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

так то дистрибутор обязан предоставить код (в данном случае патчи) по требованию

Обязан предоставить тот, кто распространяет. И не по требованию, а либо в общедоступном месте, либо вместе с бинарниками, либо предоставить письменное обязательство предоставлять по требованию в течении не менее 3 лет. В случае ASPLinux и 3 года прошло и их сервер http://asplinux.ru/ давно умер.

Сам компьютер с ASPLinux можно передать на основании ст 1272 ГК РФ (легально приобретённый экземпляр всегда можно передать другому владельцу). А вот написанные программы, слинкованные с GPL библиотеками, так как по GPL программа с библиотеками является единым продуктом и для распространения к ней необходимо предоставить исходники.

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

ситуация, конечно, неприятная, но я не вижу как она доказывает несовершенство GPL

да и нарушение GPL вполне практически обоснованное — получатель твоего программного комплекса будет не в состоянии изучить и модифицировать его в полной мере

actionless ★★★★★
()

MIT/GNU Scheme заточен под программирование больших приложений с быстрым циклом разработки.

А такие есть вообще, большие приложения на схеме? Да ещё и с «быстрым» (whatever and how really «fast» it is) «циклом разработки»...

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

ситуация, конечно, неприятная, но я не вижу как она доказывает несовершенство GPL

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

Причём один из выборов совсем грустный: или «я разрешаю использовать на любых условиях одобренных FSF» (GPL version <X> or later>) или «мой код не будет работать с новыми версиями (L)GPL библиотек» (GPL version <X> only). Самое смешное, что библиотеку LGPL3 можно использовать в проприетарной программе, но нельзя в GPL2 only.

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

Тут писали что теперь и SICP преподяют на основе Python 3.5 https://habr.com/post/282986/ Тут его уже нету https://ocw.mit.edu/courses/find-by-topic/#cat=engineering&subcat=compute...

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

SICP преподяют на основе Python

Это неправда. В заголовке статьи, ссылку на которую вы привели, ясно написано «в MIT больше не изучают SICP». Что явно противоречит вашему высказыванию.

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

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

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

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

«Зачем Юникод когда есть KOI8-R?»

Ясно-понятно. Я уж думал кто-то реально замену решился делать, как у меня в дальних планах есть.

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

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

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

Всё правильно. В некоем институте перестали преподавать некий курс SICP, который основан на Lisp, потому что этот курс больше не нужен. Действительно (соображаю я), раз Lisp не нужен для работы, то и для обучения он плохо подходит.

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

раз Lisp не нужен для работы, то и для обучения он плохо подходит.

Многие вещи, не нужные для работы, прекрасно подходят и даже необходимы для обучения. Не в этом дело.

Просто этот курс был сугубо инженерный, даже не для программистов, насколько я понимаю.

Вот причины смена курса (подчёркивание моё):

По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.

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

Подход «анализ через синтез», используемый в SICP, когда вы строите большую систему из простых, маленьких частей, стал неактуальным. Сегодня мы программируем «методом тыка».

Я не столь политкорректен, как Сассман, поэтому скажу проще. В 80-х, когда создавался курс на основе Scheme и писался SICP, нужны были грамотные специалисты, способные строить с нуля сложные абстракции. Сейчас это не актуально, сейчас массово нужны хорошо обученные макаки, способные быстро наговнякать софт из кучки готовых библиотек. Отсюда и смена курса.

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