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

> Все остальное, что в язык было внесено для облегчения реализации LINQ, к самому LINQ не относится.

Пойдите на сайт микрософта и почитайте поподробнее. Это всё части проекта LINQ.

Ты дебил и быдло.

Ох уж эта анонимная школота, так возбуждается из-за несущественных вопросов.

Пойди к мамке, пусть она тебе рот с мылом вымоет. Мал ещё взрослым дядям хамить.

> код покажи

http://paste.lisp.org/display/98435

мой вопрос надо было рассматривать не сам по себе, а в контексте обсуждения; смотри следующий мой пост

> Короче, приведи какой-нибудь реалистичный пример, а то я не понимаю.

Предположим, мы прогаем шахматный движок. На быдлояве и лиспе.

на яве все переменные, которые надо передать неявно, лежат в классе

на лиспе все переменные, которые надо передать неявно являются динамическими

дальше вдруг выясняется, что хорошо бы движок запустить 2 раза: ненадолго с тактическим креном и потом со стратегическим, заморозить оба запуска, сравнить результаты (где перспективнее) и затем разморозить перспективный

при этом оба запуска должны иметь общие данные на чтение-запись (map с оценками позиций)

1. если запуск реализовать в виде нити (есть реализации мап-ов, которые работают без локов с несколькими нитями, но мы для простоты предположим, что мы нити не пускаем параллельно) то в яве придется переписывать самую малость: сделать мап статической переменной; а в лиспе? (хотя наверно тоже немного)

2. если запуск не реализовывать в виде нити? в яве придется переписывать самую малость, а сколько придется переписывать в лиспе? (да-да, неожиданно вспоминается та самая симула)

_____________________

З.Ы. передача неявных аргументов через динамические переменные — это еще худший атавизм, чем бесстековые процедуры фортрана

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

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

* динамические конечно!!!

> на лиспе все переменные, которые надо передать неявно

являются динамическими

Зачем так делать?

при этом оба запуска должны иметь общие данные на чтение-запись

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

в яве придется переписывать самую малость,

а сколько придется переписывать в лиспе?

Сколько?

> и еще, пора бы лисперам выйти из глухой обороны и предложить задачу,

где неявная передача аргументов в виде this не удобна, а удобны

именно динамические переменные

Ты продолжаешь что-то сильно путать. Возможности ООП в Common Lisp превосходят аналогичные возможности Java. Классы/объекты и динамические переменные используются для решения различных задач. Как их можно сравнивать? И главное зачем?

Впрочем, у меня есть один пример на эту тему: http://archimag-dev.blogspot.com/2010/03/restas.html

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

что ж, придется повторить сценарий по шагам:

- в начале развития проекта мы не рассчитывали, что наш код будет работать параллельно и юзали with-foobarbaz (в точности как автор cl-pdf)

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

- проект на быдлояве оказался готов к такому повороту событий (из-за классов)

- а проект на лиспе со своими with-foobarbaz устанавливающими *foobarbaz* ?

________________________________

вообще-то мне уже надоело критиковать лисп... я надеюсь что в ответ мне дадут пример «что неудобно сделать через this, но удобно через *foobarbaz*»

ну и еще интересно, как дин. переменные работают с рестартами (но я торможу придумать какой-нить пример)

> а проект на лиспе со своими with-foobarbaz

устанавливающими *foobarbaz*?

А какие с ним проблемы? Ты понимаешь разницу между динамическими и глобальными переменными?

я надеюсь что в ответ мне дадут пример

Я привёл ссылку, где я не стал делать «через this»

как дин. переменные работают с рестартами

А какие могу быть проблемы?

> Возможности ООП в Common Lisp превосходят аналогичные возможности Java.

но при этом для неявной передачи аргументов почему-то используются дин. переменные, а нее CLOS ?

> Я привёл ссылку, где я не стал делать «через this»

почитаю

А какие могу быть проблемы?

сорри я торможу щас...

например у нас есть дин. переменная А

в функции В мы сделали новое связываение для А, а затем вызвали функцию С

в С мы тоже сделали новое связываение для А, затем через рестарт попапли снова в стэковый фрейм В

1. какое связывание для А мы увидим?

2. что будет, если мы во фрейме В еще раз сделаем новое связываение для А?

> но при этом для неявной передачи аргументов почему-то используются

дин. переменные, а нее CLOS ?

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

другими словами — если мы во время рестарта попробуем создать новую «версию» дин. переменной, то куда в стэке, хранящим старые «версии», она запишется?

Простая вещь: связывание действует только внутри блока let и никак иначе, это гарантируется стандартом и реализацией. Связывание не изменяет старое значение, а только создаёт новое связывание.

в С мы тоже сделали новое связываение для А,

затем через рестарт попапли снова в стэковый фрейм В

И? Ты же не беспокоишься за судьбу лексических переменных и вообще за судьбу стэка? Реализация обеспечивает правильную обработку что бы не произошло.

что будет, если мы во фрейме В еще раз сделаем новое

связываение для А?

Будет новое связывание.

Динамические переменные работают абсолютно чётко и никаких проблем с ними нет.

Ты спрашиваешь как это реализовано в машинных кодах или что? При выходе за пределы let восстанавливается предыдущие связывание. let не изменяет глобальное состояние системы.

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

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

> но вполне возможно, я не знаю подходящих юз кейсов,

почему и спрашиваю

Раньше разработчики любили глобальные переменные (да C-кодеры их и сейчас любят), они очень удобны и просты, но у них масса недостатков. Динамические переменные - это такая улучшенная версия глобальных переменных: взяли все плюсы, и выкинули минусы.

> Ты спрашиваешь как это реализовано в машинных кодах или что?

я спрашиваю как это реализовано в терминах стэка, про который ты писал на http://lisper.ru/articles/cl-vars

Каждая форма let (и эквивалентные ей), в которой указана динамическая переменная, в начале помещает на стек новое связывание и удаляет его в конце выполнения.

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

> я спрашиваю как это реализовано в терминах стэка,

про который ты писал на http://lisper.ru/articles/cl-vars

Это не я писал, на lisper.ru нет моих статей ;) (кстати, сервер сейчас лежит - это нормально, я его обновляю)

> http://paste.lisp.org/display/98435
там все нормально работает, если учесть что callback дергается после выхода из dynamic scope let-a, вот и получается что *foo* уже в глобальном

> мой вопрос надо было рассматривать не сам по себе, а в контексте обсуждения; смотри следующий мой пост
да я уже понял что на самом деле тебе надо, даже не в плане программирования

тока какой стратегический смысл этих каверзных вопросов ? потому что:
- в лиспе все хорошо, поверь мне на слово, точнее есть некоторые вещи но на прямую к языку они не относятся
- в лиспе как правило есть несколько путей сделать что то
- делать упор на ООП подход vs лисп самоубийство
- лисп программируемый язык программирования и его можно менять под свои нужды и твои придирки

и что то мы забыли про решение на scala ?

> там все нормально работает, если учесть что callback дергается после выхода из dynamic scope let-a, вот и получается что *foo* уже в глобальном

а, т.е. динамическая привязка не сохраняется?

все, кажется разобрался.

> в лиспе все хорошо, поверь мне на слово, точнее есть некоторые вещи но на прямую к языку они не относятся

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

> делать упор на ООП подход vs лисп самоубийство

1. мы рассматриваем не ООП в целом, а всего лишь передачу неявных аргументов через синтаксис ООП

2. и самое главное — расскажи, как оно, самоубийство, получается-то?

только в конкретном случае — я передаю неявные аргументы в ООП-стиле, и тут вдруг встает задача... и у меня со своим ООП-стилем ниче не выходит... а лисперы со своими дин. переменными на белом коне

жду :-)

> и что то мы забыли про решение на scala ?

решение чего? аналога cl-pdf?

Если ты используешь объекты для передачи «неявных» параметров, рекомендую почитать Thinking In Java и осилить в конце концов ООП.

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

и вообще-то речь шла об использовании не объектов, а синтаксиса ООП (хотя может и объекты тоже можно)

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

а поможет ли это поменять под мои нужды *уже готовые* библиотеки, типа cl-pdf, *без* их переписывания?

эта нить попала в топ10 на первую страницу, так что думаю дискуссия пойдет живее

> а поможет ли это поменять под мои нужды *уже готовые* библиотеки,

типа cl-pdf, *без* их переписывания?

Что значит «поменять под мои нужды»? Если ты опять про использование *динамических* переменных, то это не надо, ибо не создаёт абсолютно никаких проблем.

Кстати, макрос pdf:with-document создаёт новое связывание переменной pdf:*document* с новым объектом класса pdf::document (вот сюрприз то!), так что, ни о каком противопоставлении *динамические переменные* vs ООП в контексте cl-pdf речи не идёт, ибо используются оба подхода.

> синтаксиса ООП

можно небольшой пример кода? а то никак не пойму, как связано ООП (тем более «ООП-синтаксис») и неявные параметры

> верю на слово, что все хорошо, пока едешь по прямой асфальтовой дороге :-) а вот вопросы типа «если я крутану руль на высокой скорости с целью кувыркнуть машину и снова стать на колеса, выдержит ли она?» надо выяснять

думаеш лисп вчера придумали и ты первый сел за руль ?)

> расскажи, как оно, самоубийство, получается-то?
потому что что все ООП в mainstream, и не только, языках и рядом не лежало с CLOS+MOP, а это всего лишь часть лиспа

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

лисперы уже на коне, у них есть свобода выбора

> решение чего? аналога cl-pdf?
http://www.linux.org.ru/news/opensource/4805165/page1#comment-4816755

> а поможет ли это поменять под мои нужды *уже готовые* библиотеки, типа cl-pdf, *без* их переписывания?

напиши свои макры defun и пр., в них сделай нужные тебе преобразования body

(setf (macro-function 'defun-orig) (macro-function 'defun))

(defmacro defun (name lambda-list &body body)
`(defun-orig ,name ,lambda-list (format t «enter: ~a~%» ',name) ,@body))

> Особенно если это Mono.

Вот с моно у немерле всё странно, разработчики про него не знают: http://code.google.com/p/nemerle/downloads/list

Ну то есть к примеру в дебиан компилятор есть в репах, но вот уже xbuild не билдил nemerle.