LINUX.ORG.RU

5-й номер журнала «Практика функционального программирования»

 , , , , , ,


0

0

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

  • Инструменты интроспекции в Erlang/OTP. Максим Трескин
  • Экономия ошибок. С. Зефиров, А. Сафронов, В. Шабанов, Е. Мельников
  • Введение в F#. Евгений Лазин, Максим Моисеев, Давид Сорокин
  • Лисп — философия разработки. Всеволод Дёмкин, Александр Манзюк
  • Оптимизирующие парсер-комбинаторы. Дмитрий Попов
  • Модель типизации Хиндли — Милнера и пример её реализации на языке Haskell. Роман Душкин

Также в этом номере опубликованы результаты конкурса, который был объявлен в 3-м номере журнала.

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

★★★★★

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

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

только вот с суждением о понимании DSL неувязочка, если вы его сделали, то вероятно у вас была уже сформированная на этот счет позиция, и в таком случае раскрыть непонимание собеседника дело 3-5 минут и предложений, и по моему, с тех пор, вы здесь уже не меньше написали

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

исходное сужени о dsl

P.S. Использующие лисп (CL по крайней мере) практически никогда не поминают DSL, согласно моему скромному конечно.

обратить внимание на подчеркнутое. Я говорил что лисперы не поминают DSL, то есть практически не употребляют этот термин (если его можно термином назвать), не ставят цель написать DSL, не называют библиотеки DSL-ями и.т.д. Новички aka недавно пришедшие в лисп или идущие к нему, DSL упоминают значительно чаще описывая легкость написания, говоря что уже написали, хотят написать этот самый DSL. Несколько отдельную часть составляют люди у которых действительно есть необходимость в специфическом языке расматривающие лисп как платформу для реализации свои задач. В статьях про DSL нередко упоминает лисп в качетве языка ориентированого на DSL, но что удивительно ни строчки кода на лиспе там не найдешь. Все бысторо скатывается на жабу и диез. Ну и россыпь непонятных ников на форумах шумящих, советующих, постояноо говорящих о DSL, но почти ничего про код и проекты. Такой срез можно получить спросив гугл про DSL и лисп. Что интересно и на руском и на английском схожая картина. Если же примера спросить у гугла о б упоминанях testing и web framework-ах и лиспа вместе. То мы получим вполне реальную картину упоминаний этих framework-ов.

Если же сходить на cliki - основной вики-ресурс по библиотекам и проектам на лиспе то можно найти видео dsl-in-lisp единственное и знаменитое

статью lisp and DSLs на умершем сайте

Упоминание о расширении для lisp-unit в виде dsl

s-path проект который декларирует что он dsl

книгу в содержании которой упоминается dsl

Отмечу что страниц cliki на пару порядков больше.

Сходим на common-lisp.net - хостинг проектов

упоминание о dsl на n-ной странице в руководстве к asdf

упоминание dsl в руководстве markdown

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

около 80 писем в архивах maillist-ов

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

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

Ну и по конец темы о которых я здесь НЕ говорил.

Использовании компиляторов лиспа для реализации динамических языков - реально интересно, ведь динамическая компиляция.

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

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

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

Если рассматривать «eDSL» не как термин, а как подход, то картина куда лучше - данный поход применяется (в разной степени приближения) в некотором, конечно не сильно большом, количестве библиотек, при этом слово DSL в явном виде авторами не упоминается, однако часто в таких случаях, библиотека чуть больше чем API, но и на eDSL еще не тянет, несомненно «системный» подход был бы предпочтительней. Но тем не менее, а в каком другом языке мы имеем лучшую ситуацию с eDSL ?, с практической точки зрения конечно.

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

Так же мне не совсем ясен смысл самого высказывания о лисперах и DSL в том посте именно мне, может я что-то не так понял ?

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

Что интересно упоминание eDSL на тех же ресурсах близко к нулю.

Расматривать подходы конечно можно, и ООП можно расматривать как процедурно-модульное и хаскель как ОО-язык. Но это расмотрение именно подхода, а не конкретной разработки. В конкретике задача будет формулироваться в других «родных» для среды терминах. И что даст именно выделение eDSL непонятно.

Кстати где по твоему граница между API и eDSL? Вобще выделяя метафоры (ну не люблю я слова паттерны) которые использутся в лиспе можно говорить о прметно-оринтированости, но есть ли там третья «Л» это вопос. И натягивать эту «Л» на DSL/eDSL как то бесмыслено.

И как бы кстати выглядел «системный» подход применения eDSL?

Чем плохи восхищения? Тем что вместо этих самых базовых метафор, идут как правило бесплодные расуждения про DSL. Ну и информационный шум он гасит все разумное, доброе, вечное.

Мне лень рассуждать о других языках. Возможно поэтому и важно для тех других языков выделять eDSL, поскольку в самих языках чего то не хватает. В жабе вон тоже в стандарте красота, а на практике spring как заменитель гибкости, груви как заменить динамики и AOP как переизобретенная standart-method-combination.

В посте была не очень тонкая ирония, на тему очень частого упоминаения DSL.

Вобще показательно

библиотека чуть больше чем API, но и на eDSL еще не тянет

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

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

>еще раз озвучу задачу:

надо создать коллекцию (вовсе не обязательно массив), в которую клались бы только объекты, на классе которых определена функция f

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

Чисто практически проблем с такими коппекциями очень мало. В много потому что доступ к ним осуществляется (как првило) из контекста где класс объекта очевиден, даже если не задекларирован.

Смена классовой принадлежности объекта редкоприменяется и по опять же практичски ее влияние не учитыват. Опять же как правило это смена класса от предка к потомку (включая mixin-ы) так что ее влияние минимально.

абстрактная коллекция хранящая объекты определенного класса характеризуются контрактом/связью межу классом объекта и классом или местонахожением (place). Такая связь выражается мультиметодом

[code=lisp] (defmethod |добавить объект| ((collection |класс коллекции|) (object |класс объекта|)) ...) (defmethod |добавить объект| ((collection (eql '|должники на текущую дату|)) (object |класс объекта|)) ...) [/code]

Вопрос с запретом измений решался бы либо опредлением соответсвующего #'change-class и соответвенного запрета измений класса для всех экземпляров класса.

Либо при «коллекционировании» менять класс объекта на подкласс относледованый от чего-то вроде frozen c соответсвующими методами.

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

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

>> Если же двинутся дальше в MOP то можно контролировать изменения класса, например для db-классов можно контролировать соответсвие схеме БД и в случае разногласий запросить помощи у програмиста предоставив возможные варианты решения в виде рестартов.

выглядит круто... но подозрение закрадывается, что тут успешно

решаются те проблемы, которых при правильном подходе вообще нет

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

А в указаном «правильном подходе» я подозреваю REPL-а у меня не будет.

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

Там по ссылке выше (срач про DSL) вопросы по терминологии и «системности» разжеваны, +есть мнение зала, еще раз спорить о терминологии желания нет, это слишком субъективная и буквоедская область.

Теперь к основному, практике, было сделано суждение (пост 22.06.2010 20:04:55) о том что с реальным DSL в lisp-е плохо, при этом ответа на вопрос - а где на практике хорошо (хотя бы где их так же легко делать и есть такой же набор полнофабрикатов) не последовало, а без этого вся остальная аргументация в стиле google ничего не нашел, выглядит как терминологическое буквоедство в вакууме.

В посте была не очень тонкая ирония, на тему очень частого упоминаения DSL.

да я понял, просто предоставил на выбор возможность не обострять, а так раз уж взялся иронизировать огласи пожалуйста свои успехи на ниве lisp + DSL в практических приложениях, а там видно будет что это было ирония или самоирония.

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

Раз уж сам взялся иронизировать, то скажу что не отделяю иронию от самоиронии. То замечание было констациией факта очевидного (по крайней мере для меня) при мониторинге лисп-ресурсов.

Теперь к основному, практике, было сделано суждение (пост 22.06.2010 20:04:55) о том что с реальным DSL в lisp-е плохо, при этом ответа на вопрос - а где на практике хорошо (хотя бы где их так же легко делать и есть такой же набор полнофабрикатов) не последовало, а без этого вся остальная аргументация в стиле google ничего не нашел, выглядит как терминологическое буквоедство в вакууме.

Если уж разбираете мои суждения, то потрудитесь приводить точные цитаты из меня же. Я нигде не писал что в лиспе плохо с реальными DSL-лями. Я писал что с одной стороны в среде лиспа это понятие почти не употребляется, с другой примерам притягиваемым на роль dsl/edsl хоть и присуща преметно-ориентированость но языками они если и являются то вырождеными. По сути становясь какими-то другими понятиями с другими качествами. И явно в конце поста написал что в лиспе есть развитые средства трансляции и инфраструктуры для DSL (неважно внутренних или внешних), но при этом сами DSL не актуальны. Хотя тут я как покажет дальнейшие рассужения несколько загнул.

без этого вся остальная аргументация в стиле google ничего не нашел

Всегда есть возможность опровергнуть гугл, ткнув в то что гугл не смог найти. Но если поправить гугл нечем, то извиняйте. То есть упоминания о реальные упоминания реальных DSL/eDSL найти давольно сложно. Если мы берем как цель вычленить неявые eDSL, то нужно точное опредление eDSL выраженное относительно терминов и элементов Лиспа как ЯП. То же самое про системный подход к eDSL.

Определение в посте http://www.linux.org.ru/jump-message.jsp?msgid=4805165&cid=4819075 подходит слабо потму как размыто довольно таки и кодм не проилюстрировано.

В том ,гм.., обсуждении не прозвучало точного определения. Но скомпилировав несколько взглядов оказалось возможным получить определение DSL применительно к лиспу пригодное для дальнейших размышлений. Согласно нему действительно получается что iterate действительно eDSL (често говоря я до этого я в этом сомневался), а вот cl-pdf в общем случае нет. Вобще я надеялся что такое определение услышу, но ...

вся остальная аргументация в стиле google ничего не нашел, выглядит как терминологическое буквоедство в вакууме.

просто предоставил на выбор возможность не обострять, а так раз уж взялся иронизировать огласи пожалуйста свои успехи на ниве lisp + DSL в практических приложениях, а там видно будет что это было ирония или самоирония.

Ну право слово детсад в стиле «а сам ты кто»

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

> Если уж разбираете мои суждения, то потрудитесь приводить точные цитаты из меня же. Я нигде не писал что в лиспе плохо с реальными DSL-лями.

«Это все статистические аргументы к эмпирическому утвеждению что лисперы не очень стремятся разрабатывать и мечтать о DSL. Тема „DSL и Лисп - вместе навсегда“ вобще ближе к информационнному шуму чем к реальным пректам. Если бы я ставил целью найти употребление слова DSL именно в реальных проектах, то нашел еще с десяток ссылок которые гасятся шумом, но вряди это изменит общее положение.»

причем на мой контр-вопрос сначала был ответ - мне лень, и только затем - я этого не говроил.

Всегда есть возможность опровергнуть гугл, ткнув в то что гугл не смог найти


извини, но я брезгаю заниматся такого рода оргументами

В том ,гм.., обсуждении не прозвучало точного определения.

Вобще я надеялся что такое определение услышу, но ...



Там и еще много где подобные общие определения характеризуют имеено суть, cl-pdf и еще много чего замечательно проходит под них, частные определения для конкретных инструментов как правило просто дополнительно завязанны на детали реализации на этом инструменте, в случае лиспа это затруднительно благодаря его гибкости и куче других замечательных свойств, да и вообще практическая ценость подобных частных определений под вопросом. Всерьез относится к такого рода терминологии и иронизировать на таких скользких вещах весьма сомнительно.

Ну право слово детсад в стиле «а сам ты кто»

кто есть кто и насколько он соответствует тому что и как он говорит пусть оценивают закусывающие попкорном

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

да да, именно это. А то у некоторых есть сомнение в мощи CL.

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