LINUX.ORG.RU

Вышел новый релиз реализации языка Common Lisp - Clozure CL 1.5

 ,


0

0

Вышел новый релиз реализации языка Common Lisp - Clozure CL 1.5. Этот релиз включает много исправлений и улучшений:

  • Изменена версия FASL файла и образа памяти по сравнению с 1.4. Для перехода на версию 1.5 необходимо пересобрать все старые FASL файлы.
  • [Mac OS X] Ядро лисп системы собрано с SDK 10.5 поэтому небходима версия Mac OS X Leopard или выше.
  • Улучшена стандартная функция CL:RANDOM. Используется MRG321k3p генератор с периодом 2^185.
  • опция PURIFY теперь поддерживается на х86 архитектурах. PURIFY'ed объекты копируются в область памяти, которая не сканируется сборщиком мусора. Pезультатом может быть увеличенная скорость сборки мусора, a также улучшено совместное использование виртуальной памяти, если одновременно запущенно несколько процессов.
  • REBUILD-CCL теперь подавляет предупреждения при измении констант.
  • Переменные ввода/вывода связанные WITH-STANDARD-IO-SYNTAX (*PRINT-BASE*, *PRINT-ARRAY*, etc.) теперь локальны для каждого треда.
  • Добавлены бивалентные векторы. Они похожи на строковые потоки, только используются векторы размером (UNSIGNED-BYTE 8).
  • Ядро системы загружает только образ памяти, имя файла которого состоит из «kernel_name» + ".image" суффикс.
  • Улучшены утилиты анализа памяти: CCL:HEAP-UTILIZATION, CCL:HEAP-IVECTOR-UTILIZATION.

Поддерживаемые платформы:

  • Mac OS X 10.5 и позже(x86, x86-64, ppc32, ppc64)
  • Linux (x86, x86-64, ppc32, ppc64)
  • FreeBSD 6.x и позже (x86, x86-64)
  • Solaris (x86, x86-64)
  • Microsoft Windows XP и позже (x86, x86-64)

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



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

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

> Ну назовите хоть один адекватно реализующий разные парадигмы язык.

C# 3.0+

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

> Невозможно в Nemerle сделать макрос, который раскроется в другое макроопределение

Космонавты бушуют.

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

Простo еще одна хорошая реализация. + поддерживает треды на всех платформах. Под Mac OS X есть родная поддержка Cocoa «изкаропки».

CL-USER
() автор топика
Ответ на: комментарий от bk_

> А тогда - чем оно хуже SBCL?

Не так превосходно, как SBCL ;)

archimag ★★★
()

отлично, надо будет обновиться

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

Ну и какие в C# парадигмы?
В нем есть нормальное функциональное или логическое или мета программирование?
Или я что-то пропустил?

Svoloch ★★★
()
Ответ на: комментарий от Sun-ch

> Nemerle, однако в нем нет [...] programming by contract в стиле Eiffel.

Wut? http://nemerle.org/Design_by_contract_macros

А вообще крайне интересный язык, жалко лишь, что потенциально мёртвый без поддержки MS.

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

> Ну назовите хоть один адекватно реализующий разные парадигмы язык.

Common Lisp?

Мимо. Попытка номер 2?

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

То, что у тебя, скорее не ReverseFor, а count_down (так как аргумент 1, а не 2)

вот как это можно на скале:

object HelloWorld {
    def count_down(n: int)(code: int=>unit) {
        var i=n;
        while(i>=0) {
            code(i); i-=1
        }
    }
    def main(args: Array[String]) {
        count_down(10) { i => println(i) }
    }
}
www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

Фичи ООП, императивщины и функциональщины присутствуют. Реализовано всё адекватно. Почему мимо?

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

> Господи, он что, оперирует строками?? Закапывай...

как обычно, безграмотность линейно коррелирует с крикливостью :-)

немерле оперирует AST

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

> Невозможно в Nemerle сделать макрос, который раскроется в другое макроопределение.

кхм... я сомневаюсь...

ну даже если и так, то зачем такое чудо надо? (в примере, приведенном санычем, for тоже макрос, это работает и этого достаточно)

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

а давай устроим сравнение возможностей метапрограммирования на скале и лиспе — лисперы ставят задачи, пишут их на лиспе, а я (может еще r подключится) — на скале

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

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

> Это не парадигма. Это даже в Erlang на уровне API сделано, с крошкой синтаксического сахара.

А виртуальная машина, а вытеснение потоков по количеству редукций ? Это тоже на апи сделано ?

немерле оперирует AST

Вдобавок ещё и с типизированным AST, плюс тайпер там мудрёный, поэтому написание нетривиальных макросов требует немалого понимания работы компилятора. А компилятор там довольно криво реализован, что и отпугивает от него =)

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

> В нем есть нормальное функциональное или логическое или мета программирование?

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

Метапрограммирование есть - см. рефлекшн и дерево выражений.

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

> Невозможно в Nemerle сделать макрос, который раскроется в другое макроопределение.

Почему же? Если я правильно понимаю, то в macro1 можно использовать macro2 в том случае, если macro2 был объявлен до macro1. В отличии от лиспа, где на макросах можно рекурсию городить (m1 через m2, а m2 в свою очередь через m1).

Ещё меня сильно интересует почему Nemerle так часто смешивают с говном? Pattern Matching там ого-го, любой OCaml обзавидуется, алгебраические типы там тоже ничем не хуже любого выкидыша ML, ООП поддерживается не намного хуже, чем в C#, c макросами разобрались.

Помню какой-то анонимус писал, что, мол, в начале изучите Nemerle (те, кто на C# кодит), а потом будет очень легко перебраться на OCaml или Haskell. По мне, так это чистой воды идиотизм (или фанатизм): менять мультипарадигменный язык с готовым (нормальным) компилятором, отладчиком, средой разработки и огромнейшей инфраструктурой (на дотнете скоро весь оффтопик зиждиться будет) на нечно академическое (против окамла ничего не имею) и без единой _нормальной_ библиотеки.

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

>А тогда - чем оно хуже SBCL?

Возможно sbcl генерит лучший машинный код - надо проверять. Требует SSE2 - старые/слабые процы в пролёте. Как и в sbcl впёрли кодировки «в себя», а не привязались к какой-либо библиотеке - этих кодировок мало.

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

>Ещё меня сильно интересует почему Nemerle так часто смешивают с говном?

С говном смешивают всё, что не могут «осилить» =)

Основная претензия к Nemerle - .net. А по мелочи - после лиспа довольно жутковатый синтаксис макр; невозможность делать локальные макры. Плюсов дофига, но .neeeeeeeeeet...

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

> programming by contract в стиле Eiffel.

В файле assertions.n есть определения макросов assert, requires, ensures, expose.

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

> то есть, однопроходное. Невозможно в Nemerle сделать макрос, который раскроется в другое макроопределение.

Зато можно делать отложенные макросы, которые раскрываются по мере получения информации о типах используемых выражений. В лиспе такого нет.

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

> Основная претензия к Nemerle - .net.

А чем плох .net? Если без идеологических и религиозных бредней - то очень неплохая технология. Особенно если это Mono.

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

> кхм... я сомневаюсь...

Не сомневайся. В Nemerle раздельная компиляция. Макры, определенные в том же модуле, не могут быть использованы. Это очень жесткое ограничение.

ну даже если и так, то зачем такое чудо надо? (в примере, приведенном санычем, for тоже макрос, это работает и этого достаточно)

Ну, если тебе только таких примитивных макр и достаточно - тогда не проблема. А если тебе нужно делать сложные eDSL, то это просто must have, без этой фичи ни хрена не получится.

В Лиспе макроопределение может использоваться тут же. Макроопределение может использовать ранее определенную функцию. Код eDSL может раскрыться в последовательность определений функций и макр - и таким образом эти eDSL писать проще всего. В Nemerle же на каждую итерацию компиляции eDSL придется отдельную dll генерить, и сложный скрипт для компиляции изобретать.

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

> а давай устроим сравнение возможностей метапрограммирования на скале и лиспе — лисперы ставят задачи, пишут их на лиспе, а я (может еще r подключится) — на скале

Давай. Задача 1 - сделать исключительно на метапрограммировании альтернативный синтаксис, который позволял бы самого себя расширять.

Задача 2 - eDSL с альтернативной, отличной от языка-носителя системой типов.

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

Все задачи сугубо практические.

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

>А чем плох .net? Если без идеологических и религиозных бредней - то очень неплохая технология. Особенно если это Mono.

Чем плох? Если без всего, что ты назвал «идеологическими и религиозными бреднями» (ты видно в пробирке родился и там-же растёшь/живёшь) - моноплатформенен. А Mono ещё слишком «слаб», как по сравнению со «старшим братом», так и по сравнению с главным конкурентом. Итог один - обоих в сад.

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

> Почему же? Если я правильно понимаю, то в macro1 можно использовать macro2 в том случае, если macro2 был объявлен до macro1.

Он еще и в другой DLL должен быть (если используется внутри самого макроопределения). Извращение ужасное. Для любого хоть немного сложного DSL, который компилируется в несколько этапов, придется создавать с десяток DLL-ок.

Ещё меня сильно интересует почему Nemerle так часто смешивают с говном? Pattern Matching там ого-го, любой OCaml обзавидуется,

Не так уж и ого-го.

алгебраические типы там тоже ничем не хуже любого выкидыша ML, ООП поддерживается не намного хуже, чем в C#, c макросами разобрались.

Макросы убогие, ADT с очень нетривиальными ограничениями, что делает его еще сложнее чем OCaml.

Помню какой-то анонимус писал, что, мол, в начале изучите Nemerle (те, кто на C# кодит), а потом будет очень легко перебраться на OCaml или Haskell. По мне, так это чистой воды идиотизм (или фанатизм): менять мультипарадигменный язык с готовым (нормальным) компилятором,

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

на нечно академическое (против окамла ничего не имею) и без единой _нормальной_ библиотеки.

F#, однако.

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

> Чем плох? Если без всего, что ты назвал «идеологическими и религиозными бреднями» (ты видно в пробирке родился и там-же растёшь/живёшь) - моноплатформенен.

Ясно. Кроме идеологических бредней и детсадовской ненависти к MS ничего назвать не можешь.

А Mono ещё слишком «слаб», как по сравнению со «старшим братом», так и по сравнению с главным конкурентом. Итог один - обоих в сад.

Чем же это Mono слаб? Говноформочки не рисует? Так говноформочки и не нужны. Как VM он ничуть не хуже. Вот скоро новый GC прикрутят, так будет и намного лучше.

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

>Кроме идеологических бредней и детсадовской ненависти к MS ничего назвать не можешь.

А ты так крепко сел задом на MS, что «моноплатформенность» мимо ушей пропустил? Ну и патенты пока ни кто не отменял.

Чем же это Mono слаб?


Сам порисуй бенчи между 3-мя платформами и докажи, что Mono не слаб. А пока он обыкновенный ублюдок (за определением ублюдка - в википедию)

так будет и намного лучше


если бы у бабушки были яйца...

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

>> и что у Nemerle c REPL?

В смысле?


В смысле - я просто не в курсе: он там есть? Что-то слышал пару лет назад про nemerlesh, но там вроде был ряд ограничений

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

> В смысле - я просто не в курсе: он там есть? Что-то слышал пару лет назад про nemerlesh, но там вроде был ряд ограничений

Есть «Nemerle Interpreter» (nemish.exe). Я его сильно не использовал. Наверное, похожий на F# Interactive.

dave ★★★★★
()

Ни у кого, кстати, не завалялись спеки по второму F#? А то research.offtop.com делиться не хочет — почитать хотел что они там наворотили.

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

Ну или я давно не смотрел, или у нас разные взгляды.
То что я видел, это было функциональным программированием в стиле
c++/java т.е. уродливенько, бессмыслененько, но можно.
А статьи по метапрограммированию в C# вызывают у меня стойкий ужас.
Видимо lisp меня испортил.

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

Ну если знать предыдущие вариации то да.
Но если lisp знать, все равно как-то блин... Хочется убежать подальше.

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

Может, они и практические, но более-менее понятно сформулирована только 3-я. Хотя не очень понятно, что такое «определение переменных» - присваивание?

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

> Может, они и практические, но более-менее понятно сформулирована только 3-я.

Они не для тебя формулировались. Что тебе ничего не понятно будет, это как бы и так очевидно. Ты малограмотен.

Хотя не очень понятно, что такое «определение переменных» - присваивание?

Определение - это и есть определение. Binding, то есть. «let x = 1 in бла-бла-бла.»

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

> Все задачи сугубо практические.

но сформулированны слишком абстрактно

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

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

> Ну или я давно не смотрел, или у нас разные взгляды. То что я видел, это было функциональным программированием в стиле c++/java т.е. уродливенько, бессмыслененько, но можно.

Вы давно не смотрели. LINQ - это практически полноценная ленивая функциональщина, с лямбдами, замыканиями, выведением типов и прочей музыкой.

А статьи по метапрограммированию в C# вызывают у меня стойкий ужас. Видимо lisp меня испортил.

Очевидно, испортил. Вы вот скажите, сильно оно надо-то, метапрограммирование? Я там понимаю, накачать им пару ходовых библиотек, чтобы синтаксис получался поизящнее. Немножко приятнее жить становится. А дальше? Каковы профиты-то?

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

> Они не для тебя формулировались.

излишняя экспрессия повредит дискуссии :-)

а задачи надо сказать интересные

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

> Вы вот скажите, сильно оно надо-то, метапрограммирование? Я там понимаю, накачать им пару ходовых библиотек, чтобы синтаксис получался поизящнее. Немножко приятнее жить становится. А дальше? Каковы профиты-то?

Да, сильно надо. Для того, чтобы делать eDSL всяческие.

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

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

> Все задачи сугубо практические.

Как тут верно заметили, это далеко не очевидно. Задачи не самодостаточны, они явно вспомогательного характера - т.е. помогают решать какие-то другие задачи, с реальным практическим результатом.

Вопрос: а так ли необходимо эти реальные задачи решать через DSL и МП? Почему не подходит простое использование библиотек? Или разработка собственного языка и транслятора к нему?

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