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

Разработчик и так де-факто каждый раз создаёт новый язык, составляя словарь понятий предметной области и реализуя их в виде классов, методов и т.п. Вопрос стоит в том, чтобы сделать создание этого языка и выражение мыслей на нём максимально удобным. Когда, чтобы выразить простую мысль в терминах предметной области, приходится продираться сквозь дебри синтаксиса ЯП и его искусственных ограничений... — нахрена нужен такой язык вообще?

> Когда, чтобы выразить простую мысль в терминах предметной области, приходится продираться сквозь дебри синтаксиса ЯП и его искусственных ограничений... — нахрена нужен такой язык вообще?

затем, что за «дебрями синтаксиса ЯП» стоит универсальность, совместимость и стандарты, может самому писать DSL и интересно, но пользоваться чужими, разными для всех задач, и расширять их под себя - отнюдь

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

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

> может самому писать DSL и интересно, но пользоваться чужими, разными для всех задач, и расширять их под себя - отнюдь

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

за «дебрями синтаксиса ЯП» стоит универсальность, совместимость и стандарты

Получилась красивая, но бессодержательная фраза. Универсальность чего, совместимость с чем и стандарты на что?

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

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

Нахуа? Максимально удобным, а не достаточно удобным. А это это уже нищебродство получается.

> Нахуа? Достаточно удобным, а не максимально удобным. А то это уже дрочерство получается.

Ок, достаточно удобным. Дело в том, что сами знаете какие языки — не _достаточно_ удобны для.

> Вы не в состоянии осознать, что любая библиотека — по своей

сути DSL для своей предметной области?

Такими заявлениями вы полностью обесцениваете само понятие DSL. Однако оно имеет ценность. Но как и любую другую мощную концепцию её не стоит применять для всего подряд.

> Такими заявлениями вы полностью обесцениваете само понятие DSL. Однако оно имеет ценность. Но как и любую другую мощную концепцию её не стоит применять для всего подряд.

В случае расширяемых языков нет жесткой границы между библиотекой и DSL.

Rake — это уже DSL или еще библиотека для Ruby? Tk — библиотека виджетов или DSL на основе Tcl для построения интрефейсов?

>> Вы не в состоянии осознать, что любая библиотека — по своей сути DSL для своей предметной области?

Такими заявлениями вы полностью обесцениваете само понятие DSL.

Ну почему же «обесцениваете»... просто ставит понятие «DSL» на причитающееся ему место.

Разница лишь в том, делать это нормально или через жопу.

возьмем пример - нужно отрисовать PDF поверх окна gtk, очень условно говоря с помощью библиотек это пишется так:

GString str = GString_new( "Hello World" );
Window wnd( str );
wnd.show();

FString path ( "file.pdf" );
File    file ( path );
MemBuf  buf  ( file.ReadAll() );

Poppler pl  ( buf.get() );
Cairo   cr  ( wnd );

pl.Draw( cr );

ничего сложного - все очевидно; а теперь покажи как это запишется через DSL, как ты это видишь, ну что GString, File, Window, FString, MemBuf, Poppler, Cairo - все разные DSL, т.е. как именно это все будет выглядеть поверх все-равно так необходимого универсального ЯП( чтоб DSL вообще можно было связывать между собой )

нужно отрисовать PDF поверх окна gtk, очень условно говоря с помощью библиотек это пишется так

ничего сложного - все очевидно

Капитан, ты?

т.е. как именно это все будет выглядеть поверх все-равно так необходимого универсального ЯП( чтоб DSL вообще можно было связывать между собой )

Ты полагаешь, что если такая формулировка ставит в тупик тебя, то она поставит меня? Расширяй кругозор, начни с Ruby, например. Для начала, можешь попытаться ответить на простой вопрос: является ли программа на Rake программой на Ruby. Затем можно переходить к более сложному: является ли код, исполняющийся в man n interp, программой на Tcl.

Именно тот факт, что любой код на специализированном DSL, созданном на расширяемом языке, является одновременно и кодом на самом этот языке, и делает языки, подобные, скажем, Лиспам, Io или Ruby, такими мощными. (Хотя в скобках заметим, что в отдельных случаях язык можно не только расширять, но и урезать. Например, в том же man n interp.)

а теперь покажи как это запишется через DSL, как ты это видишь, ну что GString, File, Window, FString, MemBuf, Poppler, Cairo - все разные DSL

Если для определённости взять некий ruby-подобный псевдокод, то эта лапша будет выглядеть где-то так:

wnd = Window.new("Hello World")
pl = Poppler.new(IO.read("file.pdf"))
wnd.show
pl.draw_on wnd.cairo_context

> Если для определённости взять некий ruby-подобный псевдокод, то эта лапша будет выглядеть где-то так:

То есть не отличимо от кода, который привел лестер.

> То есть не отличимо от кода, который привел лестер.

Что ты этим хотел сказать, и кто такой лестер?

>> То есть не отличимо от кода, который привел лестер.

Что ты этим хотел сказать

То, что ты привел такой же код на универсальном языке, пользующийся библиотеками. Где там DSL?

кто такой лестер?

aho

возьмем пример - нужно отрисовать PDF поверх окна gtk

Тривиальней пример нельзя было выбрать? Ты б еще б хелло ворлд рассмотрел бы.

> То, что ты привел такой же код на универсальном языке, пользующийся библиотеками. Где там DSL?

Ты тоже не в состоянии осознать, что программа на Rake является программой на Ruby?

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

Я могу гнуть язык как угодно под задачу, но он всё равно останется тем же самым языком. Я так понял, ваша претензия в том, что видимый синтаксис остаётся без изменений? Так там и нечему изменяться: и в лиспах, и в Ruby, и в Io, и в Tcl синтаксис как таковой практически отсутствует. А вам что, хотелось увидеть, как у ЯП вырастут рога и хвост?

> А вам что, хотелось увидеть

Нам бы хотелось увидеть DSL, К.О.

> Ты полагаешь, что если такая формулировка ставит в тупик тебя, то она поставит меня? Расширяй кругозор

Если для определённости взять некий ruby-подобный псевдокод, то эта лапша будет выглядеть где-то так:

замечательно конечно, вот только это не набор DSL, ты оказывается просто неуч, нет - может конечно лично для тебя DSL это что-то вроде макросов или тех же библиотек, но на самом деле DSL - это ЯП, как, например, тот же PL/SQL, ЯП со своим синтаксисом, своей лексикой, и хрен ты вот так просто напишешь:

wnd = Window.new(«Hello World»)
DROP TABLE T2
cursor = SELECT * from T1
wnd.title = cursor.f1.value

без указания какой именно DSL тебе нужен

> Ты тоже не в состоянии осознать, что программа на Rake является программой на Ruby?

В состоянии (а в скобках замечу, что с Руби я познакомился раньше, чем ты).

Я так понял, ваша претензия в том, что видимый синтаксис остаётся без изменений?

За этой претензией идет гораздо более глубокая - кто и как проверяет программу на DSL.

Так там и нечему изменяться: и в лиспах, и в Ruby, и в Io

Не надо Лисп сюда приплетать. Его макры работают в compile-time, умеют проверять и трансформировать код. В Руби это есть? Нет, IIRC.

> Тривиальней пример нельзя было выбрать?

Пример ведь не совсем тривиальный, правда? Попробуй написать такое на pure-'твой любимый язык'. Тривиальным его делает использование готовых библиотек. Большинство задач требует комбинации нескольких готовых библиотек с некоторым количеством собственной логики. И лучше всего для этого подходит универсальный ЯП. А использование DSL может быть оправданно только для относительного небольшого круга задач.

> замечательно конечно, вот только это не набор DSL, ты оказывается просто неуч

Аргументы кончились, переходим к прямым оскорблениям?

DROP TABLE T2

SELECT * from T1

Внезапно, drop table t2 и select all from t1 могут быть вылидным кодом, например, на Tcl. Ну синтаксис конкретного языка накладывает определённые ограничения, и что? Что это доказывает?

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

Я так понимаю, ты уже определился с тем, является ли Rake DSL-ем?

> Аргументы кончились

да - на ваши веские доводы у меня нет аргументов, разрешите откланяться

> Не надо Лисп сюда приплетать. Его макры работают в compile-time, умеют проверять и трансформировать код. В Руби это есть?

Да успокойся ты уже со своей статической типизацией и проверками в compile-time. Если 100 раз повторить один и тот же вброс, он станет очень унылым.

> И лучше всего для этого подходит универсальный ЯП. А использование DSL может быть оправданно только для относительного небольшого круга задач.

И чем более универсальными становятся универсальные ЯП, тем меньше остаётся круг для «настоящих DSL». Конфиг к программе на Tcl удобнее всего хранить на самом Tcl. А еще можно хранить разметку гуя, запросы к БД, описания парсинга аргументов командной строки, тысячи их...

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

Но все-таки такой круг задач есть, да? Например, yacc отцы юникса не смогли оформить в виде библиотеки.

И лучше всего для этого подходит универсальный ЯП. А использование DSL может быть оправданно только для относительного небольшого круга задач.

А почему одно исключает другое? Правильный DSL - это DSEL.

> Но все-таки такой круг задач есть, да?

Да, такие задачи есть.

Например, yacc отцы юникса не смогли оформить в виде библиотеки.

Отцы юникса писали на С и придумали DSL, ибо писать всё на C большой напряг. Другие люди, вместо того, что бы изобретать разные DSL, просто придумали более высокоуровневые языки программирования.

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

...и пишут на них DS(E)L.

> А почему одно исключает другое?

Бритва Оккама же.

Правильный DSL - это DSEL.

Почему?

Ну, аналоги яка есть почти для всех языков, даже для высокоуровневых. http://javacc.java.net/ http://www.dabeaz.com/ply/

Бритва Оккама же.

Подробнее, пожалуйста.

Почему?

Ну, собственно, по той самой бритве. Язык с расширением в виде DSEL проще, чем отдельно язык и отдельно DSL.

Другое дело, что далеко не все языки дают удобные инструменты для создания хороших DSEL. Лисп в этой области покруче C, Хаскель ещё круче.

>> Бритва Оккама же.

Подробнее, пожалуйста.

Зачем городить DSL, если с ним не получается лучше, чем без него?

Язык с расширением в виде DSEL проще, чем отдельно

язык и отдельно DSL.

Э, нет. Так нельзя говорить. Я как-то смотрел eDSL для генерации HTML на Haskell - выглядело впечатляюще, но только я бы таким всё равно не стал пользоваться, ибо это должно быть в отдельном DSL и в отдельных файлах.

Вообще, если предметная область стоит того, что бы городить для неё DSL, то велика вероятность, что для этой области есть предметные специалисты. И было бы хорошо, если бы они могли работать с этим DSL без надобности работать с «основным языком», ибо ведь DSL будет намного проще, чем универсальный язык + eDSL.

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

> Да успокойся ты уже

В отличие от тебя, я спокоен.

Если 100 раз повторить один и тот же вброс, он станет очень унылым.

Ну а как еще вас учить?

Зачем городить DSL, если с ним не получается лучше, чем без него?

Так не получается лучше.

«Делайте всё настолько проще, насколько возможно - но не проще».

Я как-то смотрел eDSL для генерации HTML на Haskell - выглядело впечатляюще, но только я бы таким всё равно не стал пользоваться, ибо это должно быть в отдельном DSL и в отдельных файлах.

Ну вот, сам говоришь, что нужен DSL.

Вообще, если предметная область стоит того, что бы городить для неё DSL, то велика вероятность, что для этой области есть предметные специалисты. И было бы хорошо, если бы они могли работать с этим DSL без надобности работать с «основным языком», ибо ведь DSL будет намного проще, чем универсальный язык + eDSL.

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

А потом предметному специалисту понадобится какая-нибудь мелочь, в этот DSL не входящая...

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

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

>> Зачем городить DSL, если с ним не получается лучше, чем без него?

Так не получается лучше.

Во-первых, не перевирай. Я сказал, что c DSL должно быть лучше, чем без него. Во-вторых, что с ним получается лучше надо обосновывать и не абстрактными рассуждениями.

Ну вот, сам говоришь, что нужен DSL.

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

А что, предметный специалист будет сильно страдать от осознания,

что DSEL, с которым он работает - на самом деле часть основного

языка?

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

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

Только в том случае, когда DSL по тем или иным причинам нельзя

удобным образом реализовать как внутренний.

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

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

Ну так это зависит от используемого основного языка.

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

Значит, надо брать язык, где правила НЕ причудливы и замысловаты.

Вообще да, иногда специалист УЖЕ привык к некоему языку, и ему будет неудобно с DSEL. В качестве примера - тот же HTML; верстальщику будет ПРОЩЕ работать с более-менее обычным HTML, чем, скажем, с Haskell-комбинаторами. И тут уже надо смотреть, что выгодней - переучить верстальщика, или делать внешний DSL, напоминающий HTML. Но таких ситуаций не так уж много.

Внутренний DSL это удар по модульности

Это ещё с чего вдруг???

Вот я в своё время всерьёз собирался писать свой ЯП. Неприятным открытием оказался масштаб работы. Любой мало-мальски полноценный ЯП общего назначения имеет исходник (компилятор + рантайм) порядка 5-6мб. Сравнив это со скоростью написания мной кода (или портирования чужого кода) я понял, что задача создания ЯП ни в какой мере не является тривиальной.

Полноценная же работа с ЯП подразумевает не только существование компилятора/интерпретатора, но и:

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

Я не совсем понимаю, о чём говорят люди, когда говорят, что задача создания ЯП - тривиальна?

Покажите мне средство, на котором я могу тривиальным образом создавать совершенно новые языки. В лиспе я не могу решить все эти задачи тривиальным образом. Они решаются, но с существенными трудозатратами. Я думаю, что в лиспе меня спасает то, что на самом деле, такая задача почти никогда не возникает - я пишу набор макросов и вот тебе «DSL». Один раз такая задача возникла, я её решил, но назвать эту работу тривиальной у меня что-то язык не повернётся.

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

> Значит, надо брать язык, где правила НЕ причудливы и замысловаты.

Намекаете на JavaScript? Да, хороший язык.

Я не совсем понимаю, о чём говорят люди, когда говорят, что задача создания ЯП - тривиальна?

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

я пишу набор макросов и вот тебе «DSL».

Без кавычек. Да, это лисповский способ делать DSEL. Способ довольно корявый, макросы - это тебе не first-class objects, но более-менее неплохой.

Вообще, у меня такое впечатление, что ты неправильно понимаешь, что такое DSL. Это не язык, на котором мы будем писать ВСЁ, и тем более не язык, который мы будем продавать. Это язык, на котором мы будем писать некоторую часть, помогающий основному языку, а не заменяющий его. А потому «библиотеки», «треды» и т.п. присутствуют только тогда, когда это нужно.

Намекаете на JavaScript? Да, хороший язык.

Намекаю на хаскель. В жабоскрипте как раз много всякой грязи.

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

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

А пока можно посмотреть на такое:

http://www.jetbrains.com/mps/

но о тривиальности конечно речь не идет

> Намекаю на хаскель

Зря. Его синтаксис, в любом случае, можно назвать спорным.

В жабоскрипте как раз много всякой грязи.

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

Намекаю на хаскель.

Не, Дэвид Блейн. Синтаксис Хаскеля трудно отнести к его достоинтсвам. Он несколько перегружен.

> Лисп в этой области покруче C, Хаскель ещё круче.

Толсто же. Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

Нужно быть проще и люди к тебе потянуться. Всё перечисленное нужно только для широко используемого языка общего назначения. Интерпретатор C-подобного языка пишется максимум за неделю. На C++. Это исключительно личный опыт.

Он прост и естественен для большинства людей, имеющих какое-либо отношение к программированию.

Depends. Два наиболее известных DSL-я - это HTML и SQL. Каждый из них в жабоскриптовом синтаксисе будет выглядеть очень нелепо. В Хаскельном SQL можно сделать почти таким же, как есть сейчас, а HTML... ну, более-менее похожим.

Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

Не узнаю вас в гриме? Love5an?

Синтаксис Хаскеля трудно отнести к его достоинтсвам. Он несколько перегружен.

Ну, «специалисту» о лишнем грузе можно не говорить, так ведь? Зато он последователен и в то же время достаточно гибок. Если уж BASIC сделали DSEL-ем...

Хаскель по части написания ДСЛ от сишки-то не далеко ушел, с лиспом же это убожество даже сравнивать смешно.

Воистину аноним хуже...

> Два наиболее известных DSL-я - это HTML и SQL.

Э, закончили разговор, HTML это язык разметки, к DLS никаком боком отнести его нельзя.

Э, закончили разговор, HTML это язык разметки, к DLS никаком боком отнести его нельзя.

Почему это - нельзя??? Ну, не тьюринг-полный (я не учитываю веяния CSS3), ну и что? Чем он хуже вполне тьюринг-полного PostScript, который применяется примерно для того же, но при этом является диалектом Forth-а?

JSON не в состоянии заменить HTML как язык разметки? К слову, можно ли считать hamlet (такая библиотека для генерации html из кода на haskell использующая TH) eDSL'ем? Он пожалуй строгое надмножество html.

JSON не в состоянии заменить HTML как язык разметки?

Подкузьмил. Способен.

> Два наиболее известных DSL-я - это HTML и SQL.

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

> что характерно - оба замечательно выглядят в

лиспоподобном синтаксисе.

HTML хреново, SQL тоже не бог весь как, но для SQL хотя бы выполняются важные вещи (типа защиты от sql-инжекций).

оба замечательно выглядят в лиспоподобном синтаксисе.

В лиспоподобном синтаксисе хреново выглядит даже Лисп.

> Почему это - нельзя???

Потому что HTML это не язык программирования, вообще. На нем не программируют. А то так ведь можно и картинки в формате SVG в DSL занести. Ещё раз - HTML это не DSL, ни в одном месте.

Чем он хуже вполне тьюринг-полного PostScript

Вы много писали на PostScript? Я довольно много. И общего между PostScript и HTML не наблюдаю вообще ничего.

Потому что HTML это не язык программирования, вообще. На нем не программируют.

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

А то так ведь можно и картинки в формате SVG в DSL занести.

Ну да, естественно.

И общего между PostScript и HTML не наблюдаю вообще ничего.

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

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

информации в структурированном, человеко-читабельном виде.

Не, html задуман для семантической разметки данных (если забыть про это, то сейчас это больше дизайнерский инструмент), а PostScript для управления стэковой машиной.

Не, html задуман для семантической разметки данных (если забыть про это, то сейчас это больше дизайнерский инструмент), а PostScript для управления стэковой машиной.

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

> Это никак не отменяет того факта, что предназначения их сходны.

Нет, у них принципиально разные назначения. Это вообще очень разные вещи.

> В лиспоподобном синтаксисе хреново выглядит даже Лисп.

В лиспоподобном синтаксисе все выглядит прекрасно. Для хаскеля верно обратное.

> А потом предметному специалисту понадобится какая-нибудь мелочь, в этот DSL не входящая...

кстати да, вот написали «свой лисп» при реализации R и таки loop (ввиду безнадежно засахаренного синтаксиса итерате даже не рассматриваем :) никто не портировал. И что бы это было удобно сказать не могу, одними *apply тоже скучно бывает писать.

я - den73

> Интерпретатор C-подобного языка пишется максимум за неделю.

И где сейчас этот интерпретатор?

И где сейчас этот интерпретатор?

Там где и полагается ему быть — в помойке её сдал какой-то отрицательный студент как свою работу. Для себя я C-подобных языков не пишу.

Всё не так просто. Что считать синтаксисом Хаскеля? Нечто определённое в стандарте как haskell2010? Так им никто же не пользуется! Многочисленные расширения расширяют и синтаксис. Причём так расширяют что при использование квазицитирования ломается list comprehensive, а внутри квазицитирования не работают списки (последнее впрочем может относиться только к hamlet'у). Добавим ко всему прочему синтаксические сахара… С другой стороны возможность легко и непренуждённо определять свои операторы в плане создания языков-подмножеств хороша. Это если не брать во внимание, что любая монада по сути и есть маленький eDSL.

> при использование квазицитирования ломается list comprehensive

Интересно, УМВР. Ссылку на пример поломки можно?

а внутри квазицитирования

Работает свой парсер, никакого отношения к Хаскелю не имеющий.

> Причём так расширяют что при использование квазицитирования ломается list comprehensive, а внутри квазицитирования не работают списки

Надежный хаскель - такой надежный.

Это если не брать во внимание, что любая монада по сути и есть маленький eDSL.

Монада - это один единственный простенький макрос. причем один на _все_ монады. понятно теперь, что подразумевают хаскиебы, когда говоря о «ДСЛ в хаскеле».

А ты не тот самый дядя, который путает классы типов с полиморфными типами?

Причём так расширяют что при использование квазицитирования ломается list comprehensive, а внутри квазицитирования не работают списки

Но ломает что-то, как я понимаю, только квазицитирование. Которое, вроде как, last resort. Остальные расширения внедряются в синтаксис незначительно, ничего не нарушая.

Монада - это один единственный простенький макрос.

К счастью, нет. Монада – это один тип и две функции.

> К счастью, нет. Монада – это один тип и две функции.

Там о монадах шла речь в контексте ДСЛ, так что, видимо, имелась в виду do-нотация. Которая - 1 единственный макрос.

Там о монадах шла речь в контексте ДСЛ, так что, видимо, имелась в виду do-нотация.

Нет, конечно.

> Нет, конечно.

Вообще-то да. Потому что монады сами по себе с ДСЛ никак не связаны.

Вообще-то да.

Нет. То есть, я, конечно, не могу ручаться за автора того коммента, но подобное высказывание достаточно распространено в Haskell-среде, и имеет совершенно определённый смысл.

Потому что монады сами по себе с ДСЛ никак не связаны.

Нет. Но довольно часто оказывается удобным сделать DSL монадическим.

> Нет. То есть, я, конечно, не могу ручаться за автора того коммента, но подобное высказывание достаточно распространено в Haskell-среде, и имеет совершенно определённый смысл.

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

Нет. Но довольно часто оказывается удобным сделать DSL монадическим.

Вобщем-то нет, такого никогда не бывает. По крайней мере на данный момент ни одного подобного «монадического ДСЛ» не существует.

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

Что не отменяет того факта, что он есть.

Вобщем-то нет, такого никогда не бывает.

Чем Parsec не DSEL, например?

> Что не отменяет того факта, что он есть.

Нет, любители хаскеля как раз предпочитают придавать смысл тому, в чем смысла нет. Чтобы было загадочней. Монады - яркий том пример. Блестящий просто троллинг - развести столько хайпа вокруг тривиальной банальщины.

Чем Parsec не DSEL, например?

Нууу... тем что он не DSEL.

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

Ну-ну. Зайди на кафедру высшей алгебры в каком-нибудь приличном ВУЗе и расскажи, что монады – тривиальная банальщина и никому не надо.

Нууу... тем что он не DSEL.

Фу, ну не надо так бездарно сливать.

> Ну-ну. Зайди на кафедру высшей алгебры в каком-нибудь приличном ВУЗе и расскажи, что монады – тривиальная банальщина и никому не надо.

А при чем тут монады в математике? Вот возьмем мешок картошки - можно рассматривать его как множество, согласно аксиоматике ZFC и блаблабла, но для любого нормального человека мешок кратошки - это просто мешок кратошки. Вот и хаскимонады так же - их можно конечно рассматривать как математические монады, но смысла в этом точно столько же, как в том, чтобы анализировать мешок картошки с позиции теории множеств. Мешок картошки - вещь тривиальная. Хаскимонады (в смысле программирования) - тоже вещь тривиальная. Просто тайпкласс с парой функций. Хотя вообще монады и с точки зрения математики вещь весьма простая.

Фу, ну не надо так бездарно сливать.

А чем он ДСЛ?

Нууу... тем что он не DSEL.

Приведи пример DSEL пожалуйста и разъясни что его делает DSEL'ем.

А при чем тут монады в математике?

При том, что это то же самое.

Вот возьмем мешок картошки - можно рассматривать его как множество

Нельзя.

Просто тайпкласс с парой функций.

Угу. И математическая монада тоже – всего один функтор и пара функций.

Хотя вообще монады и с точки зрения математики вещь весьма простая.

Да. Но необходимая.

А чем он ДСЛ?

Сформулируй своё понимание DSL, а то утомил слегка.

>Мешок картошки - вещь тривиальная. Хаскимонады (в смысле программирования) - тоже вещь тривиальная.

Я не понимаю что ты этим хочешь сказать. Если подходить с такой позиции, то все получается тривиально.

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

Во-первых, уместнее говорить о тройке Functor/Applicative/Monad. Во-вторых, если уж и говорить о монадах, то говорить «монадический интерфейс к...». В-третьих, монады, описанные в многочисленных туториалах в реальной жизни НЕ используются, в реальной жизни приходится пользоваться монадическими трансформерами. В-четвертых, более «продвинутые» интерфейсы типа Arrow не «пошли» именно из-за своей «продвинутости».

В-четвертых, более «продвинутые» интерфейсы типа Arrow не «пошли» именно из-за своей «продвинутости».

Ой, не сказал бы.

У меня от Arrow впечатление, скорее, чего-то, сляпанного на скорую руку. Они не overcomplicated, они undercomplicated.

> Зайди на кафедру высшей алгебры

Ты бы еще на кафедру высшей арифметики послал.

> Нельзя.

Можно, конечно.

При том, что это то же самое.

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

Угу. И математическая монада тоже – всего один функтор и пара функций.

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

Да. Но необходимая.

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

Сформулируй своё понимание DSL, а то утомил слегка.

Почему я-то? Ты и формулируй. Ты же начал утверждать, что Х - ДСЛ. Вот и объясняй, что ты под этим понимаешь.

Можно, конечно.

Ну, если сидишь в психушке, то можно.

мешок картошки, вдобавок к тому, что множество - еще и гладкое многообразие

Мешок картошки не является ни множеством, ни многообразием.

Не функций, а естественных преобразований.

Ну да. Функций в категории эндофункторов.

в теоркате есть целый ряд эквивалентных монадам конструкций

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

Почему я-то?

Потренируешься.

> Я не понимаю что ты этим хочешь сказать. Если подходить с такой позиции, то все получается тривиально.

Нет, тривиальным получается то, что тривиально, и только это.

Во-вторых, если уж и говорить о монадах, то говорить «монадический интерфейс к...».

Нет, не монадический интерфейс, а именно монада.

Во-первых, уместнее говорить о тройке Functor/Applicative/Monad.

Зачем говорить о тройке, если говоря о монаде я сразу говорю о функторе и об аппликативном функторе, т.к. монада ими является?

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

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

В-четвертых, более «продвинутые» интерфейсы типа Arrow не «пошли» именно из-за своей «продвинутости».

Наоборот.

Нормальную композицию монад в хаскеле сделать не удалось

Она вообще невозможна. Математически. Композиция (математических) монад не обязана сама быть монадой.

> Ну, если сидишь в психушке, то можно.

ВсЕ, кто пишут на хаскеле - сидят в психушке? Я знал, я знал!

Мешок картошки не является ни множеством, ни многообразием.

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

Ну да. Функций в категории эндофункторов.

Не функций, а стрелок. Или морфизмов, на худой конец. Иди учи уже определения, дебил.

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

Нет, объекты-то разные. Просто ведут себя одинаково.

Потренируешься.

Мне-то зачем? Это же ты ничерта не знаешь. Вот и просветишься.

ВсЕ, кто пишут на хаскеле - сидят в психушке?

Нет, только те, кто путает мешок картошки с множеством.

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

О, ну, давай-давай, сформулируй определение множества, послушаем.

Не функций, а стрелок.

Угу. В теоркате понятия «функция», «стрелка» и «морфизм» употребляются как синонимы.

> Она вообще невозможна. Математически. Композиция (математических) монад не обязана сама быть монадой.

Вопрос еще в том, что такое «композиция (математических) монад».

Нет, объекты-то разные.

Одинаковые с точностью до изоморфизма. А мелкие технические различия никому не интересны.

Мне-то зачем?

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

Вопрос еще в том, что такое «композиция (математических) монад».

Ну, термин «композиция» имеет вполне определённое значение, вообще-то.

Или ты пользуешься собственным определением? Тогда формулируй.

> Нет, только те, кто путает мешок картошки с множеством.

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

О, ну, давай-давай, сформулируй определение множества, послушаем.

Под «множеством» мы понимаем соединение в некое целое M определённых хорошо различимых предметов m нашего созерцания или нашего мышления (которые будут называться «элементами» множества M).

Ну или через аксиоматику. Мы можем делать с мешком картошки все, что нам разрешают делать с множеством аксиомы теории множеств.

Угу. В теоркате понятия «функция», «стрелка» и «морфизм» употребляются как синонимы.

Не употребляются. Потому что чуть менее, чем всегда, стрелки не являются функциями.

> Одинаковые с точностью до изоморфизма.

До изоморфизма где?

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

Я умею, все ок.

> Ну, термин «композиция» имеет вполне определённое значение, вообще-то.

Композиция монад? Давай определение.

Под «множеством» мы понимаем соединение в некое целое M определённых хорошо различимых предметов m нашего созерцания или нашего мышления (которые будут называться «элементами» множества M).

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

Я умею, все ок.

Только скрываешь.

Композиция монад?

Монада есть функтор. Композицию функторов определять?

Чем Parsec не DSEL, например?

Нууу... тем что он не DSEL.

Конечно, потому что это internal DSL :)

> Понятно, что такое «определение» ты тоже не в курсе.

Да, как и Георг Кантор. Вот такие мы с ним два идиота - не знаем, что такое определение :( А еще, там специально для тебя была приписка - можно определить и аксиоматически. Ну например, проще всего определить пусто множество. Х есть пустое множество, если Х может быть элементом множества и если Х не содержит никаких элементов (все по ZFC, короче). Пустой мешок удовлетворяет обоим этим свойствам, а значит, является пустым множеством.

> Монада есть функтор.

Чушь, конечно. Одному функтору может соответствовать куча разных монад. Можно сказать, что _некоторые функторы_ являются _классами эквивалентности монад_. не более того.

Композицию функторов определять?

Нет, композицию монад, пожалуйста. Там кроме функтора еще два естественных преобразования и пара свойств.

Да, как и Георг Кантор. Вот такие мы с ним два идиота - не знаем, что такое определение

Ты ещё Архимеда вспомни.

Нормальные определения пошли где-то с Гильберта.

Х есть пустое множество, если Х может быть элементом множества и если Х не содержит никаких элементов (все по ZFC, короче). Пустой мешок удовлетворяет обоим этим свойствам, а значит, является пустым множеством.

Не-а. Пустой мешок не может быть элементом множества. Элементами множества могут быть только математические объекты, в число коих мешок не входит.

Одному функтору может соответствовать куча разных монад.

Да, разумеется.

Точно так же на одном множестве можно ввести кучу структур группы.

Что не отменяет того факта, что группа есть множество.

Нет, композицию монад, пожалуйста. Там кроме функтора еще два естественных преобразования и пара свойств.

О чём я и говорю: композиция монад может не быть монадой. Для соответствующего функтора может не найтись таких естественных преобразований.

> Не-а. Пустой мешок не может быть элементом множества. Элементами множества могут быть только математические объекты, в число коих мешок не входит.

В ZFC нигде ничего не говорится про какие-то «математические объекты». Там вообще никаких объектов нету - там есть только переменны. а какие значения эти переменные могут принимать - зависит от интерпретации, которую мы выберем. Никто не запрещает нам выбрать в качестве интерпретации мешки, главное, чтобы такие мешки удовлетворяли аксиомам. Они и удовлетворяют.

> Что не отменяет того факта, что группа есть множество.

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

О чём я и говорю: композиция монад может не быть монадой.

Я еще раз задам вопрос - что такое композиция монад?

Я еще раз задам вопрос - что такое композиция монад?

такой ответ тебе подойдёт?

>>Группа - это не множество, группа - это упорядоченная тройка.

Садись. Двойка.

> Группа - это не множество, группа - это упорядоченная тройка.

Какая ещё тройка? Группа это множество и групповая операция на нём вида X*X -> X, где X - групповое множество(плюс групповая операция должна удовл. опр. условиям).

Группа это множество и групповая операция на нём

строго говоря, это ещё и нейтральный элемент относительно этой операции. любая группа является моноидом

хотя в любом случае это буквоедство. можно ведь сказать и так, что группа - это алгебра F a -> a (с некоторой сигнатурой F). что толку в подобном терминологическом споре, если все понимают, о чём идёт речь?

> Какая ещё тройка?

Тьфу ты. Пара, конечно же, а не тройка :)

> строго говоря, это ещё и нейтральный элемент относительно этой операции. любая группа является моноидом

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

> Группа это множество и групповая операция на нём вида X*X -> X
А ещё нейтральный элемент, и всё это добро пишут как тройку (впрочем, это зависит от учебного пособия).

>Depends. Два наиболее известных DSL-я - это HTML и SQL. Каждый из них >в жабоскриптовом синтаксисе будет выглядеть очень нелепо. В Хаскельном >SQL можно сделать почти таким же, как есть сейчас, а HTML... ну, >более-менее похожим.

Я сначала тоже думал, как круто - завернуть SQL в скобочки. А потом столкнулся с ситуацией, когда надо скопипастить пример из мануала.

И что? Оборачивать его в скобочки? Или строкой передавать? Но если передаёшь строкой,то возникают другие проблемы: " превращается в \".
Вроде мелочь, но если проводишь за SQL 8х5 в неделю, это - серьёзный недостаток.

В итоге пришёл к тому, что синтаксис SQL должен остаться неприкосновенным. Т.е.,

(fbody select 1 as «поле» from dual^)

А если нужно поумничать, то пишется препроцессор не сложнее cpp,но в начинке у него - весь лисп:

(fse master.*, detail.* from detail M_INNER_JOIN(detail,ref_master);
)

макрос M_INNER_JOIN разворачивает данные из словаря в join и получается:

select master.*, detail.* from detail inner join master on detail.ref_master=master.id

В общем, я понимаю, что никто не воспринимает мой совет поступать так. Типо, это недостаточно заумно. Но мне просто смешно слушать ваши рассуждения, о том, как можно один синтаксис представить другим. Можно-то оно можно, но НА-ХРЕ-НА?

В PHP HTML выглядит точно как HTML. Поэтому, на PHP будут писать сайты и дальше, а на Хаскеле их будут писать только полтора задрота.
Тупо из-за снижения производительности труда. До тех пор, пока не будет сделано что-то типа PHP, где HTML передаётся Verbatim.

Если ты 8x5 в неделю копипастишь SQL-запросы из примеров в мануале, то очень жаль. И да, HTML в Haskell выглядит в точности как HTML.

> И да, HTML в Haskell выглядит в точности как HTML.
Вы с Miguelem определитесь, он выглядит в точности или почти в точности?

8x5 в неделю копипастишь SQL-запросы

Толсто.

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

Вы с Miguelem определитесь, он выглядит в точности или почти в точности?

Hamlet строгое надмножество html. Не исключаю что Мигель с ним не знаком или видел его в те времена когда он выглядел «почти как html».

Толсто.

Именно.

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

Я немного участвовал в проекте symbolicweb. Там использовался parenscript, моя задача была сделать видгеты. Там нужно было как раз брать готовый код html и шаблонизировать его, чтобы порождать соответствующие куски из лиспа. И именно тогда у меня созрело убеждение, что прямые цитаты из html почти всегда лучше, чем обёрнутые в скобочки.

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

Например,

(let1 fld-list '(a b c)
  (fse ~~`("," ,@fld-list)) from foo;
     )

select a,b,c from foo;

> прямые цитаты из html почти всегда лучше, чем обёрнутые в скобочки

Естественно, но в том же PHP всё больше используют шаблоны. Сама идея совмещения разметки с логикой, изначально реализованная в php/jsp/asp/т.п. оказалась неудачной. Поэтому данное свойство PHP уже давно не является каким-либо реальным преимуществом. И не может служить обоснованием того, почему тот же Haskell хуже подходит для веб-разработки, чем PHP (для этого есть другие причины). Кстати, в этой связи упомянутый Hamlet выглядит вещью довольно бесполезной и надуманной и годится только для демонстрации некоторых заманчивых свойств Haskell.

Hamlet строгое надмножество html

В принципе, зачЁт. Только я не понял одного- можно ли инлайнить эти шаблоны прямо в исходник Хаскеля? Я-то могу инлайнить SQL (и, потенциально, любой другой язык) прямо в лисповый код:

(defun foo ()
  (fse 1 from dual;
     ))

Именно.

Не знаю, на что ты намекаешь. Я NIH синдромом не страдаю. Если есть где скопипастить - я это делаю и это экономит много времени. Кроме того, иногда по требованию заказчкика/начальства нельзя помещать в продукт код на лиспе. Кроме того, бывает коллективная разработка с людьми, не знающими лиспа.

Кроме того, всякие «слои поверх», как правило, упускают некоторые нюансы. В случае с SQL таких нюансов очень много и они меняются вместе с версиями сервера.

Кроме того, в случае SQL, есть ещё хранимые процедуры. Есть ли у Хаскеля слой поверх языка хранимых процедур?

И вообще, зачем мне нужно тебя в чём-то убеждать? Время, когда я любил программирование, прошло, теперь это для меня - просто ремесло.

Хочешь ломать мозг об всякие «слои поверх» - ломай. Это твой мозг.

> Сама идея совмещения разметки с логикой, изначально реализованная в php/jsp/asp/т.п. оказалась неудачной.

Возможно, но это утверждение будет слишком общим, если применять его для любого языка и любой задачи. Когда-то она будет неудачной, а когда-то - удачной. Не знаю про веб, но смесь SQL и клиентского языка - это вещь вполне осмысленная.

При работе с AJAX/COMET нужно генерировать много мелких строчек на JS. Так вот, в виде чистого JS с подстановками, в духе моих макросов для SQL, это будет выглядеть более читаемо, чем в виде скобочек, я в этом убедился на практике. Например, потому, что в JS можно использовать разные виды кавычек, а в лиспе - нет.

Да, я кстати забыл ещё об одной мелочи: отлов синтаксических ошибок.
Если я пишу select * from zoo (вместо foo), я получаю ошибку синтаксиса. SQL говорит мне конкретное место в тексте, где произошла ошибка. Когда у меня исходный код является инлайном в лиспе, я могу точно определить место _своего_ исходника, где находится ошибка. И я могу это автоматизировать, так что, нажатием одной кнопки сразу попадаю на место ошибки.

Когда у тебя «слой поверх», ты получишь место ошибки относительно сгенерённого исходника на SQL. Найти соответствующее место в твоём исходнике, написанном на «слое поверх» и показать его - это задача нетривиальная и не факт, что она вообще разрешима в рамках твоей среды разработки. В итоге, слой поверх замедляет поиск синтаксических ошибок, и чем выше уровень его абстракции, тем сильнее замедляет. Я помучался с этим некоторое время, перешёл на инлайн и с тех пор меня всё устраивает.

> При работе с AJAX/COMET нужно генерировать много

мелких строчек на JS.

Хм, зачем?

> > При работе с AJAX/COMET нужно генерировать много

мелких строчек на JS.

Хм, зачем?

Я не помню, это было 2 года назад. Я не занимаюсь вебом. Видимо, для обработки событий видгетов.

А, ну так нужно и говорить, что не при работе c AJAX/COMET, а во всяких извращениях типа SymbolicWeb ))

Только я не понял одного- можно ли инлайнить эти шаблоны прямо в исходник Хаскеля?

Можно. И подставлять в них функции Haskell тоже можно.

> Не знаю про веб, но смесь SQL и клиентского языка - это вещь вполне осмысленная.

Ну да, то-то столько ORM'ов понаворатили...

Для С-подобного языка можно найти готовые грамматики для любого *сс. Так что можно уложиться еще быстрее.