LINUX.ORG.RU

Вышел GNU Guile 2.0.0

 , ,


0

1

Guile — это официальный язык расширений проекта GNU.

Данный релиз является первым стабильным релизом ветки 2.0.x и содержит множество изменений по сравнению с веткой 1.8:

  • Поддержка исполнения кода на трёх языках: Scheme, Emacs Lisp и ECMAScript.
  • Компиляция кода программы в байткод, который интерпретируется виртуальной машиной. Это позволило существенно улучшить скорость работы.
  • Поддержка метакоманд в REPL. Например, мета-команда ,compile компилирует переданное выражение, а команда ,profile профилирует исполнение переданного выражения.
  • Режим отладки в REPL. Если код вызывает ошибку, то включается режим отладки, в котором доступны метакоманды, позволяющие посмотреть стек вызовов, узнать значения переменных и т.п.
  • Реализована встроенная поддержка syntax-rules и syntax-case систем гигиенических макросов, не требующая импорта модуля (ice-9 syncase).
  • Строки Scheme могут содержать любые Unicode символы.
  • Частично поддержан стандарт R6RS. Оставшиеся несоответствия можно посмотреть в мануале.
  • Новый динамический FFI. Теперь возможно создание биндингов к библиотекам без создания кода на C.
  • Теперь используется Boehm-Demers-Weiser консервативный сборщик мусора.

Кроме того, добавлен ряд модулей:

  • (srfi srfi-45), предназначенный для реализации ленивых вычислений;
  • (system base lalr) для генерации парсеров LALR(1);
  • набор модулей (sxml ...) для работы с XML.

Сайт проекта

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

★★

Проверено: maxcom ()

Неделя Scheme на ЛОРе, ура!

o ()

Вечерело, а языки всё выходили и выходили. Сначала Java, потом Mono, теперь это. Некоторые уже не справляются нести свою единственно верную точку зрения в трёх темах кряду.

uuu ()

> Частично поддержан стандарт R6RS.

Как-то неубедительно звучит.

Пишут же, что реализовано «a large subset of R6RS» - во всяком случае в info-gnu Digest Vol 99, Issue 8 именно так написано.

OldFatMan ()

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

Zylon80 ()

но вообще - чейнлджлог доставляет

lazyklimm ★★★★★ ()

Радует: байткод, нормальные макросы, unicode, новый ffi.

Не радует: R6RS

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

Во всяком случае, startup time у Scheme традиционно высокий. Я пробовал несколько разных реализаций, но с Tcl или Lua они не могли сравниться.

mind ()

Мда... Конечно, для начинающего я бы это не посоветовал, но при знании и правильном использовании приёмов результат просто поражает наповал.

anonymous ()

> в мануале

в документации

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

>> в мануале

в документации

в грамоте премудрой

o ()

> Поддержка исполнения кода на трёх языках: Scheme, Emacs Lisp и ECMAScript.

OMFG. Чем дальше, тем больше я ненавижу bloatware подход, принятый в проекте GNU.

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

> Радует: ... unicode ...

Прослезился :`-] 21 век, где-то осознали, что есть страны помимо америки.

matumba ★★★★★ ()

> Поддержка исполнения кода на трёх языках: Scheme, Emacs Lisp и ECMAScript.

А что, проекту GNU давно стоило емакс со сраного елиспа перевести на человеоческую схему. Потом добавить поддержку расширений на яваскрипте, это щас гламурно, потом переименовать емакс в какое-нибудь Fugunity или ZakaZaka Social Editor, на сайте добавить мокрого пола и «Share This», сорцы переложить на гитхаб, объявить от этом в твиторе, и ящитаю, это будет хит.

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

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

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

Встречный вопрос - а когда туда добавят вижуал бейсик и поддержку bat-файлов?

Manhunt ★★★★★ ()

>ECMAScript.
Зачем?!

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

Хорошо.

Строки Scheme могут содержать любые Unicode символы.

Отлично.

unikoid ★★★ ()

>ECMAScript

Хм, теперь можно будет скриптовать что-нибудь на js? Неплохо.

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

Guile нет, Racket есть. Но Guile ЕМНИП тормознее намного.

naryl ★★★★★ ()

> Поддержка исполнения кода на трёх языках: Scheme, Emacs Lisp и ECMAScript.

можно запилить свой емакс с блекджеком и фуррифоксами ?

anonymous ()

Объясните, почему в двух самых популярных реализациях Scheme используются исключительно убогие консервативные сборщики мусора? Или при уборке за Схемой они волшебным образом перестают быть убогими?

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

Новый Guile не уступает Racket в скорости. Старый раза в 2-2.5 медленнее.

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

> Мда... Конечно, для начинающего я бы это не посоветовал, но при знании и правильном использовании приёмов результат просто поражает наповал.

интересная эта гуля для скриптования... вот например скрипт http://gitorious.org/nixpkgs/nixpkgs-svn/blobs/svn/trunk/maintainers/scripts/... : лезет на сайт GNU проектов, проверяет, обновился ли пакет, и если да, обновляет его. Качает wget-ом, использует xml.

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

C LuaJIT могут сравниться следующие реализации: Bigloo, Stalin, Ikarus. Помедленнее будут Ypsilon и Gambit. Можно также взглянуть на Larceny. Guile пока далековато до LuaJIT'а.

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

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

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

> можно запилить свой емакс с блекджеком и фуррифоксами ?

взять к примеру ezbl
http://www.haxney.org/search/label/ezbl или luakit
и вотнуть его через XEmbed http://www.emacswiki.org/emacs/EmacsXembed
и ещё нотификации через D-Bus прикрутить, и другими приложениями дёргать
http://emacs-fu.blogspot.com/2009/01/using-d-bus-example.html

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

> есть ли принципиальные причины использовать консервативные GC, или есть причины по которым в Схеме и консервативный достаточно хорош,

в случае с Gambit, это наверное, http://www.iro.umontreal.ca/~feeley/papers/LaroseFeeleyIMM98.pdf со страницы Marc Feely http://www.iro.umontreal.ca/~feeley/ и в некоторой степени http://portal.acm.org/citation.cfm?id=286873

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

Я про Racket и Guile, но за первую статью спасибо.

naryl ★★★★★ ()

>Поддержка исполнения кода на трёх языках: Scheme, Emacs Lisp и ECMAScript.

ECMAScript

Таки v8 можно заменить этим? Или как это понимать?

Wizard_ ★★★★★ ()

Емакс какой-то толстый... можно
1. взять Qt-Hemlock: http://gitorious.org/hemlock/hemlock/trees/master
У него нет раскраски и кнопки не как в GNU Emacs, а так вполне работает.
2. воткнуть туда Elisp через Guile. Ради раскраски и различных modes.
..... воткнуть куда-нибудь через XEmbed или D-bus ...
3. !!! PROFIT!!!

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

Это понимать так, что теперь Guile, как и Racket умеет много разных синтаксисов: JS, Elisp, Scheme, brainfuck, infix и прочие.
Странно, что не написали про brainfuck и infix syntax http://www.gnuvola.org/software/guile/doc/Reading-Infix.html (или через Infix macro https://github.com/marcomaggi/infix).

Собственно, такое (разные синтаксисы) умеет любая нормальная реализация схемы.

Таки v8 можно заменить этим?


нет, потому что v8 это полноценный JS движок на С++. А этот синтаксис просто синтаксический сахар к всё той же схеме.
Замена синтаксиса схемы на синтаксис например, питона не делает её автоматически питоном и менее схемой. Это всё тот же язык, всё та же семантика, но с другим синтаксисом (который уже хуже или лучше подходит для выражения семантики схемы, чем исходный базовый схемы).
Поэтому замена будет скорее всего неполноценная, насколько именно, нужно проверять, тестировать. Например, в v8 уже готовый DOM, а тут придётся городить свои какие-то костыли, благо что все запчасти вроде sxml похоже на месте.
Радует однако, что такие финты ушами возможны.

Идея, которую озвучивает Guile была в том, чтобы вместо нескольких разных языков расширения приложений (в одном Lua, в другом JS, в третьем Elisp, в четвёртом sendmail.cf и т.п.) иметь один универсальный, в который остальные транслировались бы автоматически.
А расширения пользователь писал бы в синтаксисе любого языка, на котором ему удобно — всё равно они все оттранслировались бы в конечном итоге в схему Guile.

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

> 2. воткнуть туда Elisp через Guile. Ради раскраски и различных modes.

стоп. У нас уже есть TeXmacs, расширяемый через Guile. Интересно, емаксовые модули вроде org-mode там заработают?

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

>> Радует: ... unicode ...

Прослезился :`-] 21 век, где-то осознали, что есть страны помимо америки.

Не так. Есть штаты, где говорят на странных языках.

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

>Идея, которую озвучивает Guile была в том, чтобы вместо нескольких разных языков расширения приложений (в одном Lua, в другом JS, в третьем Elisp, в четвёртом sendmail.cf и т.п.) иметь один универсальный, в который остальные транслировались бы автоматически.

Ясно, спасибо за объяснение. Что ж, надо будет посмотреть.

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

> можно запилить свой емакс с блекджеком и фуррифоксами ?

Замена elisp движка в емаксе на guile — это одна из целей разработки последние несколько лет. Так что запилят.

kim-roader ★★ ()
Ответ на: комментарий от naryl

Консервативные сборщики мусора безопасны при использовании с C кодом (ну кроме пары исключений). Так как Guile изначально проектировался как разделяемая библиотека, а не как самостоятельный интерпретатор, то одним из требований к нему была корректность работы при любом C коде с которым libguile линкуется b необходимо чтобы сборщик мусора не удалял объекты на которые ещё остались ссылки в C. Так в случае кода «long a = (long) get_SCM_object();» у программы на C уже нет указателя, но есть объект, который можно будет в будущем использовать для доступа к объекту. Такие казусы могут обрабатывать только консервативные сборщики мусора.

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

> Консервативные сборщики мусора безопасны при использовании с C кодом (ну кроме пары исключений). Так как Guile изначально проектировался как разделяемая библиотека, а не как самостоятельный интерпретатор, то одним из требований к нему была корректность работы при любом C коде с которым libguile линкуется b необходимо чтобы сборщик мусора не удалял объекты на которые ещё остались ссылки в C. Так в случае кода «long a = (long) get_SCM_object();» у программы на C уже нет указателя, но есть объект, который можно будет в будущем использовать для доступа к объекту. Такие казусы могут обрабатывать только консервативные сборщики мусора.

Really? А нельзя этот объект пометить как такой, на который есть ссылка? И потом разрешить выкинуть его после вызова какой-нибудь release_SCM_pointer(ptr)?

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

>> можно запилить свой емакс с блекджеком и фуррифоксами ?

Замена elisp движка в емаксе на guile — это одна из целей разработки последние несколько лет. Так что запилят.

Лучше бы они нормальный текстовый редактор в emacs запилили. >:-)

rtvd ★★★★★ ()

Надо же, сколько новых прикольных фич. Байткод-это очень полезная идея, теперь Guile не отстаёт от Python и в этом плане. Что касается нововведений в REPL, то они тоже хороши. Ну и поддержка ECMAScript и Emacs Lisp тоже пригодится. Тем более, что ECMAScript - замечательный язык, и как и Scheme, способен потеснить Python во многих сферах. Иметь выбор из нескольких альтернатив всегда приятно, а наступление на Desktop приложений на скриптовых языках и даже на HTML5 - всего лишь вопрос времени. Очень уж многие молодые разработчики полюбили сверх-высокоуровневость и динамику.

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

Со временем так и сделают, только насчёт github не уверен. Кажется, RMS не любит выставлять GNU'ые проекты на чужие сервера. Тогда отпадёт необходимость в их портале, где попутно чел с идеологией знакомится.

lucentcode ★★★★★ ()
Ответ на: комментарий от kim-roader

> при любом C коде с которым libguile линкуется b необходимо чтобы сборщик мусора не удалял объекты на которые ещё остались ссылки в C. Так в случае кода «long a = (long) get_SCM_object();» у программы на C уже нет указателя, но есть объект, который можно будет в будущем использовать для доступа к объекту. Такие казусы могут обрабатывать только консервативные сборщики мусора.


в Gambit (cм. http://www.iro.umontreal.ca/~gambit/Gambit-inside-out.pdf ) для этого используют разные стеки С-объектов и схемовских объектов. Хотя сборщик мусора тоже консервативный.
А вот в RScheme http://en.wikipedia.org/wiki/RScheme (cм. ftp://cs.indiana.edu/pub/scheme-repository/imp/rscheme/rscheme.ps.gz ) — realtime precise cборщик мусора, так что это возможно, хотя и сложнее в реализации.

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