LISP и DSL

Отсуствие^WУниформный синтаксис же.

Не ясно, чем s-exp'ы выигрывают у рубишного человекопонятного синтаксиса.

> Чем набор лисповских символов отличается от такого

же набора в питоне, например?

В питоне есть символы?

Твой аватар лжёт. Хотя вопрос поддерживаю.

В питоне есть символы?

Имелись в виду не лисповские, конечно же. Обозвал так набор функций/типов, реализующих предметную область.

Секспы это не только код, но и данные. Так что ты можешь секспы преобразовывать в другие секспы - это собственно и делают маркы. В руби код!=данные, поэтому так нельзя сделать.

> Не ясно, чем s-exp'ы выигрывают у рубишного человекопонятного синтаксиса.

Грамматика проще.

В руби код!=данные, поэтому так нельзя сделать.

Еще раз оговорюсь. Вопроса разработки не касаемся. Пример:

Я питонист, накропал себе абстракцию для управления wm. Достаточно высокоуровневый, чтобы повседневные задачи решать в три строки.

Будь я лиспером, какой профит дали бы лисповские функции (повторяющие те же абстракции) в плане удобства пользования dsl?

> Вопроса разработки не касаемся.

Ты мне в предидущем треде сам иронически намекал на тюринг-полноту :)

> Будь я лиспером, какой профит дали бы лисповские функции (повторяющие те же абстракции) в плане удобства пользования dsl?

Тебе не кажется, что это зависит от твоих «абстракций управления WM»?

Ты мне в предидущем треде сам иронически намекал на тюринг-полноту :)

Это я и хочу выяснить. Зависит ли удобство пользования dsl, если не учитывать время потраченное на разработку. Ясен перец, что чем быстрее и короче реализация, то лучше. Но причем тут тогда dsl? Это просто язык такой выразительный.

твоих «абстракций управления WM»?

Я не против, если кто-то подберет удобные для лиспа абстракции.

чем быстрее и короче реализация

быстрее написана, конечно.

Макросы Лиспа позволяют тебе расширить добавить новые синтаксические конструктции (loop, например). В том же питоне (подставь любой язык без поддержки макросов) есть list comprehensions, но ты не можешь сделать их аналог с большей функциональностью (Generalised (SQL-Like) List Comprehensions в GHC). В Common Lisp отсутствует сопоставление с образцом, но оно может быть реализовано макросами. Лисп можно расширить средствами логического программирования (см. Racklog).

Макросы Лиспа позволяют тебе расширить добавить новые синтаксические конструктции

Ocaml, Scala… Лисп далеко не исключителен.

В Лиспе в общем случае нет макросов.

Возьмем CL и схему.

> может быть реализовано макросами. Лисп можно расширить средствами

Можно, можно, даже на ассемблере. Нахрен оно надо на каждый чих колесо изобретать?

В Схеме их тоже нет в общем случае :) Лисп для DSL'ей хорош тем, что язык-то базисный: в нем реализована одна единственная структура данных — точечная пара, и некоторые средства для работы с ней. Это дает немалую изотропность кода и данных. Все, что вам надо (или даже только вам и надо) очень просто построить поверх этого базиса. С этой точки зрения интересно также обратиться к Форту.

> Все, что вам надо (или даже только вам и надо) очень просто построить поверх этого базиса

очень просто

Мде. Это похоже на диагноз.

Ocaml, Scala… Лисп далеко не исключителен.

Да, любой язык в котором есть макросы.

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

В Лиспе в общем случае нет макросов.

Но в распространённых диалектах она есть (CL, Scheme, Clojure, ELisp).

В Схеме их тоже нет в общем случае :)

Есть как минимум гигиеничные.

> Да, любой язык в котором есть макросы.

Крамольную мысль скажу... я в питоне делал макросы (для каких то своих частных случаев, типа свою ф-ю eval с макросами). И Вы тут меня натолкнули на мысль, что можно сделать макросы и в общем виде перегрузив модуль __builtins__, только не понятно нужно ли;-)

очень просто построить поверх этого базиса

Давай возьмем реальные примеры. racket как набор dsl или апи emacs. Тупо функции.

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

2) Простота. Это тупая задача на набивание мяса. На других языках ничуть не сложнее делать ту же самую работу.

Да все правильно. Кастую archimag-а в тред. Он уже не раз заявлял, что написание макросов в лиспе - это не повседневная штука.

По теме. Сахарок - это все херня. Какой-то сахарок можно примерно эквивалентно хоть в руби накатать, хоть в лиспе, это да. Вот когда дело касается новой семантики... Пример. Нужно сделать synchronous-like синтаксис для асинхронных операций. Тут уж хоть усрись с DSL, нету у тебя continuation-ов (ну или хотя бы со-программ), не вытянешь цепочку колбеков в линейный код.

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

Ну напиши на Python или Ruby, которая реализует сопоставление с образцом.

> Ну напиши на Python или Ruby, которая реализует сопоставление с образцом.

А в чем проблема? Ближайший аналог - регулярные выражения.

Ну напиши на Python или Ruby, которая реализует сопоставление с образцом

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

Но в повседневной жизни паттернматчинги никто не пишет!

В стандарте — да, но, к сожалению, не все их реализуют.

> Пример. Нужно сделать synchronous-like синтаксис для асинхронных операций.

.NET parallel extensions отлично ложится на объектную модель.

Ну, если говорить сухо и не фантазировать, все языки в общем-то равны. Ощущение «крутости» какого-то определенного языка проходит довольно быстро.

Во что-то лисповидное — точно :) А если еще напишете внешнюю обертку в виде s-выражение, то вообще.

Ощущение «крутости» какого-то определенного языка проходит довольно быстро.

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

> Но в повседневной жизни паттернматчинги никто не пишет!

А жаль.

1. Вычисления во время компиляции. Позволяет убрать лишний шаг, вроде вызова постпроцессора .class-файлов при использовании Hibernate в Java.

2. Униформность данных и кода. Позволяет просто манипулировать AST. Это круче, если альтернативы - либо формировать выражение на самом языке и потом его eval-ить (всякие питоны, жаваскрипты), либо формировать уже готовый байткод/машинный код (Java, C). Альтернатива - манипуляция AST в терминах ООП, тоже хороший вариант. Вроде в Nemerle как то так сделано.

Возможности для создания eDSL как исключительная черта лиспа - расхожий лисперский миф. Подобные так называемые «расширения языка» возможны и в mainstream-языках, хороший пример тому - {JPA,Hibernate} Criteria API. Scala вообще имеет расширяемый синтаксис «искаропки».

А на создание «большого DSL» в лиспе уйдет не меньше времени, чем в той же Java. В Java все получится еще и быстрее, благодаря наличию ANTLR и особенно JetBrains MPS.

AST можно вполне контролировать и в змее

http://docs.python.org/dev/library/ast.html

Да и еще интересно как сравнение:PLY

Объектная модель == цепочка колбеков. Parallel Extensions еще и не из той оперы :).

У вас там в дотнете есть linq, который суть монада. Это уже по-серьезней будет. Тут уже можно монаду Cont замутить и сделать synchronous-like

Я не спец по вашему дотнету, вот пример с хабра:

var test2 =
                from x in SendRequest("hello")
                let _ = WriteLine(x)
                from y in SendRequest(x)
                from z in SendRequest(x + y)
                let __ = WriteLine("select from DB: " + y + z)
                let t = selectSmthFromDB(y, z)
                select WriteFile("tmp", t);

То есть есть в язык встроенная поддержка а-ля синхронного синтаксиса for x in ... Вот вкрутить в язык такое, если изначально нету, уже как раз магия достойная DSL.

> Да и еще интересно как сравнение:PLY

PLY - довольно традиционный генератор парсеров, он непригоден для расширения синтаксиса языка.

s/for/from/

А в чем проблема? Ближайший аналог - регулярные выражения.

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

Вычисления во время компиляции.

Попытался найти пять других языков с CTFE и не таких маргинальных как лисп — не смог. Да, это полезная штука, и можно сказать исключительная.

Униформность данных и кода

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

> Короче, я хочу аналог match из ML, если по-твоему проблем нет, как я могу реализовать эту функциональность на питоне?

Так ты хочешь аналог оператора match из ML или функцию сопоставления с образцом? Первое, естественно, невозможно - синтаксис Питона нерасширяем.

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

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

в случае питона можно было было бы рассматривать добавление переменных в текущую область видимости

Этого я не сделал, но, думаю, это теоретически возможно за счет манипуляции стековыми кадрами и словарем locals. Хотя это наверняка can of worms.

Возможно я конечно сильно ошибаюсь, но разве DSL это строго расширение базового языка?

> разве DSL это строго расширение базового языка?

Нет. Но вроде в топике разговор именно об этом.

Возможно я конечно сильно ошибаюсь, но разве DSL это строго расширение базового языка?

Нет, DSL вообще может быть отдельным языком, но наиболее интересны как-раз eDSL - встроенные специализированные языки, которые расширяют базовый язык.

[перечитав топик]А все тогда пардон, согласен что все же неправомерно расширил вопрос )