LINUX.ORG.RU

Вышел GNU Guile 2.0.7

 , , ,


1

3

Вышла новая версия реализации языка Scheme — GNU Guile 2.0.7. Несмотря на незначительное изменение номера версии, появились несколько интересных нововведений, а именно:

  • Полная поддержка инфиксных выражений (curly-infix-expressions). Теперь вместо (* a (+ b c)) можно писать {a * {b + c}}.
  • Поддержка разных опции чтения (read option) для разных портов.
  • Поддержка вложенных директив future.
  • Специальный синтаксис для добавления путей в переменные окружения GUILE_LOAD_PATH и GUILE_LOAD_COMPILED_PATH в конец списка путей, а не в начало.
  • Исправлен недочет в функции load-in-vicinity, которая не сканировала директории, установленные в переменной %load-compiled-path.
  • Исправлен порядок поиска расширений. Теперь Guile не изменяет для этого переменную окружения LD_LIBRARY_PATH.
  • Функция make-vtable-vtable помечена устаревшей, рекомендуется использовать make-vtable и <standard-vtable>.
  • Оптимизированы вызовы equal? и eqv? для случаев, когда один из аргументов — константа.
  • Новые предупреждения компилятора -Wduplicate-case-datum и -Wbad-case-datum.
  • Многочисленные незначительные улучшения и исправления ошибок.

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

★★★★★

Проверено: tazhate ()
Последнее исправление: maxcom (всего исправлений: 4)

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

Круто - функция выглядит как формула а для написания формул применяется какой-нибудь лиспапед.

Napilnik ★★★★★
()

Просто ради интереса - что такого убер-клевого есть в лиспе, чего _нет в других языках_? На ум приходит только единообразность представления кода и данных что ИМХО далеко не так хорошо.

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

Как замена - нет. Как дополнение - да.

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

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

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

Если писать одноразовый говнокод - однозначно Python. На нём почти что любые задачи решаются быстро и поддержка его как скриптового движка много где есть. Если поддерживать готовый код на лиспе - лисп.

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

единообразность представления кода и данных что ИМХО далеко не так хорошо.

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

CLOS как пачка OO-шных шаблонов из коробки.

Инкррементный компилятор делающий динамику и самопальные dsl-и вполне шустрыми за беспалтно.

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

Не представление, работа с кодом как с данными.

Работа с кодом как с сериализованным деревом синтаксического разбора.

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

Просто ради интереса - что такого убер-клевого есть в лиспе, чего _нет в других языках_?

Сообщество же.

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

Макросы

А можно про них какой-то обзор почитать? Чем лисповские макросы так сильно отличаются от макросов других языков?

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

А она только в лиспе есть? Тот-же jvm вполне позволяет «на лету» перегружать классы.

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

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

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

CLOS как пачка OO-шных шаблонов из коробки.

Чем набор шаблонов лучше нативной поддержки ООП?

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

А она только в лиспе есть? Тот-же jvm вполне позволяет «на лету» перегружать классы.

JVM может, но далеко не идеально. И к тому же это сильно зависит от конкретной реализации.

Erlang вроде хорош.

LISP неплох, но у меня он иногда подвисал, когда я менял код на лету (было это лет пять назад на SBCL).

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

Тот-же jvm вполне позволяет «на лету» перегружать классы.

перегружать придётся и все зависимые классы (если они были уже загружены ранее) - не? И как быть с уже инициализированными «инстансами» этих зависимых классов?

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

Чем набор шаблонов лучше нативной поддержки ООП?

Он видимо имеет в виду design patterns реализованные как часть CLOS, а не CLOS макросы, что добавляют ООП. Очевидно, OOP design patterns и native OOP это ортогональные вещи.

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

JVM может, но далеко не идеально. И к тому же это сильно зависит от конкретной реализации.

Не идеально конечно, но вполне перегружает, пока меняется только «логика», а не сигнатуры.

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

Не реалтайм (по крайней мере не hard realtime), но скорость выполнения архикритична почти всегда.

Есть ECL который компилирует с применением C-шного компилятора. Он может встраивать в лисповый собраный код вызовы и целые куски кода на C напрямую, а не через ffi как все остальные.

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

перегружать придётся и все зависимые классы (если они были уже загружены ранее) - не? И как быть с уже инициализированными «инстансами» этих зависимых классов?

В яве не придется - она не дает перегружать класс, если при этом меняется его структура, т.е. набор внутренних переменных и сигнатуры методов. Что собственно и логично, поскольку при смене переменных/сигнатур - проще перезагрузить все заново.

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

Он видимо имеет в виду design patterns реализованные как часть CLOS, а не CLOS макросы

Ну если design patterns то может быть. Я не сильно хорошо знаком с CLOS чтобы объективно оценивать - хороша она по сравнению с другими языками или нет.

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

А можно про них какой-то обзор почитать?

Книга Грэма On Lisp.

Чем лисповские макросы так сильно отличаются от макросов других языков?

Тем, что они тоже на лиспе, а не на каком-то надъязыке типа c-preprocessor.

Но вообще, фигня эти лисповые макросы полная. Template haskell лучше.

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

Что собственно и логично, поскольку при смене переменных/сигнатур - проще перезагрузить все заново.

Лисп - это сверхдинамическая динамика, там нету никаких сигнатур. (точнее есть, но они опциональны и просто являются директивами оптимизации для компилятора). Поэтому, в лиспе можно перезагружать все, что хочешь. Когда настраиваешь емакс - это очень прикольно. А вот серверное приложение в продакшене я бы побоялся так хачить.

provaton ★★★★★
() автор топика
Ответ на: комментарий от chinarulezzz
# guile --version
guile (GNU Guile) 2.0.7

http://portage.perestoroniny.ru/dev-scheme/guile/

Нужно владеть веб-технологиями в первую очередь, уметь ковырять исходники на Си и Си++. Для веб-технологий ruby удобен, php широко распространен. Python в умелых руках тоже ничего - subline text 2 http://portage.perestoroniny.ru/app-editors/sublime-text/ тому пример. Хоть и многие на форуме охаивают ФП, но однако тянут в свои проекты на ООП фичи из ФП.

Думаю надо внимательнее присмотреться к чисто ФП на языках ФП.

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

Книга Грэма On Lisp.

Я что-то поменьше, на пару листов а4 крупным шрифтом про плюсы и минусы? =) У меня не стоит задача изучить лисп, мне просто интересно.

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

Когда настраиваешь емакс - это очень прикольно. А вот серверное приложение в продакшене я бы побоялся так хачить.

Вот-вот. В реальной системе с хоть какими-то ограничениями по надежности - уже применимо слабо.

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

Но если тебе реально интересно, загугли что-то типа «why lisp macros are great».

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

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

:) А жалко, поскольку что-то в таком стиле и хотелось получить. Разбирать тонны скобочек в примерах, выдаваемых гуглом на запросы по макросам - лень. Вернее жалко времени и сил, которые можно потратить на более насущные вопросы.

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

[ прекратить ! ] За последнее время тут уже столько этого лиспа в новостях на этой-той-позатой неделе было. Ежели товарищь хочет разобраться может воспользоваться поиском.

// Хотя не, наврал. Но как минимум одна в топе сидит.

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

Если вкратце, то лисповые макросы (имеется ввиду CL) позволяют работать с элементами, кхм, языка как с объектами первого класса - например, пробежаться по определению структуры и для каждого ее поля сгенерить свой код; спископодобный код лиспа удобен для трансформации и генерирования из макросов, кучу рутинного и однообразного кода можно свернуть в один красивый и гибкий вызов макроса. Reader macros тоже ок, позволяют легко и просто расширять язык дополнительными конструкциями.

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

Ежели товарищь хочет разобраться

Блин, ты ж на ЛОРе не первый день! Неужели еще до сих пор не понял, что в таких тредах спрашивают не для того, чтоб разобраться?

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

некоторые компиляторы Scheme в порядке увеличения скорости — Gambit-C, Chicken, Bigloo

А есть какой-нибудь компилятор, поддерживающий R6RS?

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

А можно про них какой-то обзор почитать? Чем лисповские макросы так сильно отличаются от макросов других языков?

Макрос в общелиспе (говорю за него) - это обычный лисповый код, который принимает на вход форму (список) и возвращает другую форму. Внутри макроса сидит обычная лисповская функция, которая трансформирует входной список. Компилятор у общелиспа многостадийный, сначала разворачиваются макросы до тех пор, пока все в голый лиспокод не переведутся.

Таким образом, если объяснять на пальцах, то макрос - это функция, которая исполняется во время компиляции.

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

перегружать придётся и все зависимые классы (если они были уже загружены ранее) - не? И как быть с уже инициализированными «инстансами» этих зависимых классов?

А что, в лиспе подобных проблем не возникнет?

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

CLOS как пачка OO-шных шаблонов из коробки.

Чем набор шаблонов лучше нативной поддержки ООП?

Имелось ввиду что CLOS нативно поддерживает штуки которые в яве добавляются шабонами.

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

В CLOS везде повально позднее связывание что в основном снимает проблему.

Экземпляры в нулевом варианте переинициадизируют измененную часть умолчальными значениями. Либо можно отдельно ать эту ситуацию, что плезно например для ORM-ов.

Для макросов у которых логика зашита непосредственно кодом, действитетельно проблема. Поэтому сложную логику выносят в compole-time функции.

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

Блин, ты ж на ЛОРе не первый день! Неужели еще до сих пор не понял, что в таких тредах спрашивают не для того, чтоб разобраться?

Да нет, мне на самом деле интересно - правильно ли я года 4-5 назад лисп пощупал, поделал даже какие-то примеры из книжки (по-моему practical common lisp) и забил на него по куче причин практического свойства. Может я какие-то убер-идеи, делающие его silver bullet пропустил.

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

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

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

P.S. Может выучить на замену питону? Что посоветуете?

Guile - это скорее встраиваемый скриптовый движок. Имхо для этого Lua намного лучше - как по скорости, так и по читабельности кода.

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

Ну если design patterns то может быть. Я не сильно хорошо знаком с CLOS чтобы объективно оценивать - хороша она по сравнению с другими языками или нет.

Аналогично. Но когда смотрел - очень нравилась. Единственная проблема была только в том, что сообщения об ошибках иногда были сложнопонимаемыми. Это, видимо, как раз из-за того, что все его конструкции сделаны через хитрые макросы. Так что когда что-то не стыкуется, то сложно определить что именно пошло наперекосяк.

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

Но вообще, фигня эти лисповые макросы полная. Template haskell лучше.

Неплохой вброс.

Но в плане метапрограммирования (а макросы / шаблоны как раз для этого и есть) haskellю до LISPа вообще-то как до луны раком.

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

Единственная проблема была только в том, что сообщения об ошибках иногда были сложнопонимаемыми. Это, видимо, как раз из-за того, что все его конструкции сделаны через хитрые макросы. Так что когда что-то не стыкуется, то сложно определить что именно пошло наперекосяк.

А вот это уже очень хреново на практике. Живо представил себе всю гамму эмоций человека, посаженного разбирать чужой код на языке, в котором даже стандартная библиотека не предоставляет внятных сообщений о косяках.

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

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

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

правильно ли я года 4-5 назад лисп пощупал

В юности все уступают соблазнам и делают ошибки.

и забил на него по куче причин практического свойства

Правильно сделал.

Может я какие-то убер-идеи, делающие его silver bullet пропустил.

Не пропустил. Потому что их нет.

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