Фраза о Лиспе...

> сделай хоть на чём-нибудь, чтобы твой мега-парсер был написан и вызывался для обработки локальных кусков кода в _одном_ файле

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

> Да что ты такой эмоциональный?

Это мои проблемы :\ :)))

> Пример - я реализовал парсер Си, и подключил его в Лисп. Насколько я понимаю, ядро Лиспа просто вызовет мой парсер в нужный момент, и парсер отдаст ядру странслированный код на Лиспе. Так? Если да, то ядро не видит кода с Сишным синтаксисом вообще, о каком debug на уровне Си-кода можно говорить?

"Смотря как сделать парсер" ;)Ь Ядро - да, не видит. Парсер - видит. Можно и Си код "дебажить", но, как-правило, так ни кто не делает.

> Применимо не только к Лиспу

Да, конечно.

> но и процедурному

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

> "Смотря как сделать парсер" ;)

Вот именно - для достижения debug и stepping придется делать совершенно отдельные движения. Так что насчет "до Пекина раком" - ты, конечно, прав, но это и к Лиспу относится :-P

> Это столько раз делали, что мне даже странно, что ты об этом не знаешь. Я не зря использовал словосочетание host language - любой, кто интересуется историей своего ремесла, меня бы понял.

Ссылку!

>> но и процедурному

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

Я хотел сказать "императивному" :)

> Вот именно - для достижения debug и stepping придется делать совершенно отдельные движения. Так что насчет "до Пекина раком" - ты, конечно, прав, но это и к Лиспу относится :-P

Зыть. Реализуя парсер си на лиспе ты на выходе _не получишь_ объектника или натив - только лисп-код с аналогичной функциональностью. Соответсвенно не вижу никакой проблемы для отладки/степпинга первоначального кода.

yyk * (*) (13.10.2006 15:18:47)

> И ровно то же самое можно сказать про питон или C++.

Для С++ такое сказать совсем нельзя. Код на С++ очень далёк от естественного языка. Вышеприведённый код на С++ страшен как смертный грех и (главное) переполнен несущественными деталями. Последнее верно и для питона, но в гораздо меньшей степени.

> И что?

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

> Это столько раз делали, что мне даже странно, что ты об этом не знаешь.

Даже у o'caml препроцессор _отдельный_, только что идёт в стандартной поставке. Его _сначала_ "учат", _потом_ используют.

> Для С++ такое сказать совсем нельзя. Код на С++ очень далёк от естественного языка. Вышеприведённый код на С++ страшен как смертный грех и (главное) переполнен несущественными деталями. Последнее верно и для питона, но в гораздо меньшей степени.

Я уже два раза приводил пример где в лиспе есть несущественные детати, а в питоне их нет.

Приведи пример где в питоновском примере есть несущественные детали, а в лиспе нет. Пример с классом FileDb не рассматривается, почему см. выше.

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

Уровень абстракции это способность к изменению семантики. При чём тут способность к изменению синтаксиса?

> Если мне нужен язык с другим синтаксисом,

Что конкретно имеется в виду под другим синтаксисом? В истории развития лиспов было много всяких синтаксических извращений. Язык это вполне позволяет делать.

> вариант с перекрыванием парсера не рассматриваем

Чтобы поменять синтаксис нужно модифицировать синтаксический анализатор. Это естественно. Требование поменять синтаксис не меняя синтаксический анализатор подобно требованию изготовить стеклянную деревяшку. Абсурд.

> Ссылку!

Извине, нету. Я читал об этом еще в бумажных книгах, когда Интернет был только за бугром :)
По-быстрому на Википедии ничего интересного не нашел. На пальцах - понятие появилось в 70-х, в
технологии баз данных, означало втраивание операторов DML в программу на языке общего назначения
(тогда - Кобол, ПЛ/1). Выглядело примерно так:

/* .. */
a = 6;
EXEC SQL SELECT FROM customers c
WHERE c.age > a;
/* .. */

Pro*C в ORACLE - насколько я понимаю, та же идея. SQLJ - реализация с сегодняшними наворотами.

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

> Чтобы поменять синтаксис нужно модифицировать синтаксический анализатор. Это естественно.

Были (экспериментальные) языки с настраиваемым синтаксическим анализатором.

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

Не-а. Такое делалось неоднократно. Но не в Лиспе :-P История рулит ;)

>Аха. Называется проектированием снизу вверх. Тока одна беда есть: >если сильно увлечься, то можно никогда не добраться до цели. >Похоже, в Лиспе именно так и происходит.

Нет, в Лиспе делается не так. В Лиспе принято язык подтягивать как можно ближе к предметной области, то есть проектирование одновременно ведется как сверху вниз так и язык снизу наращивается для наилучшего соответствия задаче. Почитайте "On Lisp" Пола Грэма, там именно про это и написано.

Ни фига себе флейм!
Я ещё такого не видел! 8)

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

Да везде так делается, не только в Лиспе

> Ни фига себе флейм!

Join the fun, как говрится :)

> Я ещё такого не видел! 8)

В РФВС тоже было круто 8)

> > Чтобы поменять синтаксис нужно модифицировать синтаксический анализатор. Это естественно.

> Были (экспериментальные) языки с настраиваемым синтаксическим анализатором.

А чем модифицируемый синтаксический анализатор отличается от настраиваемого синтаксического анализатора? :)

> Не-а. Такое делалось неоднократно. Но не в Лиспе :-P История рулит ;)

Ага, только это было настолько коряво и неудобоваримо, что остался только лисп с "модифицируемым синтаксическим анализатором" :)

> В РФВС тоже было круто 8)
?
Вооружённые Силы Российской Федерации
?

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

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

Из языков последних 15-20 лет, средствами _расширения_ (не переопределения или замены!) синтаксиса обладал, IIRC, Clipper 5.0

>> В РФВС тоже было круто 8)

>Вооружённые Силы Российской Федерации

"Российски Физики Выбирают Slackware". Мега-флейм был. Примечателен, в частности, тем, что R00T ппобещал набить рыло Антихристу, и с тех пор Антик на LOR появлялся мало. Ну и вообще было интересно 8)

>> Были (экспериментальные) языки с настраиваемым синтаксическим анализатором.

>А чем модифицируемый синтаксический анализатор отличается от настраиваемого синтаксического анализатора? :)

Подумаешь, слово неверно подобрал :-P С "расширяемым". То есть можно было вводить новые конструкции, но нельзя было менять существующие.

> Тока одна беда есть

А разве дедушка Антихрист не говорил тебе, что серебряной пули не существует?

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

Итого: по данному вопросу лисп "впереди планеты всей". А "не особо нужно" - потому что _такой ценой_. В лиспе же это "одной левой" :)

> Из языков последних 15-20 лет, средствами _расширения_ (не переопределения или замены!) синтаксиса обладал, IIRC, Clipper 5.0

Clipper... было дело. Но, имхо, его средства были чуть лучше макрозамен в си. Хотя на них даже прототипы объектов делали.

Итого lisp - other 1:0 :)

> Потому что мы получим специализированный транслятор с моего языка в host language. Потому что это можно сделать на любом языке.

Но на любом языке ты не сможешь легко и изящно иметь всю мощу host language из своего dsl'ля. А это важно. Ну и вопрос удобства конечно. На с/flex/bison/ транслятор с калькулятора замучаешься делать, я уж молчу о трансляторе нормального языка, тогда как на лиспе делается элементарно.

> Итого: по данному вопросу лисп "впереди планеты всей". А "не особо нужно" - потому что _такой ценой_. В лиспе же это "одной левой" :)

Итого: по данному вопросу Лисп не лучше и не хуже остальных.

> Итого lisp - other 1:0 :)

Итого lisp - others 0:0

> Мне казалось, что входом компилятора в PyPy планируется _любое_ подмножество Python, в том числе и полный Python. RPython - это язык реализации самого PyPy.

Насколько я понял, компиляция полного Питона не планируется. Да и как ты себе это представляешь? :) То есть, откомпилировать, конечно, можно, но всё равно большая часть работы будет происходить в рантайме. Максимум, что они тут обещают - это JIT. Ну а RPython для того и придуман, чтоб его можно было транслировать в достаточно быстный машинный код.

> ты не сможешь легко и изящно иметь всю мощу host language из своего dsl'ля.

Спорно. зависит от вкуса, не подкреплено примерами.

> На с/flex/bison/ транслятор с калькулятора замучаешься делать, я уж молчу о трансляторе нормального языка,

"Нормальных языков" - не делал. То, что делал - было не так уж сложно. Причем, если бы ограничиться синтаксисом Лиспа - вообще было бы просто (написать транслятор, а не использовать язык).

Кстати - на yacc свет клином не сошелся. Есть еще ANTLR, и не только.

> тогда как на лиспе делается элементарно.

...если имеет синтаксис Лиспа. Если нет - то придется использовать аналоги yacc.

> Итого: по данному вопросу Лисп не лучше и не хуже остальных.

Хм, у него средства есть, у других нет и быть не может. И это называется "не лучше и не хуже остальных"? Тогда я достану собственный боян: НЕ НУЖЕН ВАМ ЛИСП! ПРОТИВОПОКАЗАН!

> Спорно. зависит от вкуса, не подкреплено примерами.

Ну опровергни хоть самым маленьким примерчиком... ;)

> ...если имеет синтаксис Лиспа.

Говорили уже: синтаксис лиспа - это "нечто", имеющее начало и конец. Всё. Какой/чей синтаксис не укладывается в эти рамки?

>> Итого: по данному вопросу Лисп не лучше и не хуже остальных.

>Хм, у него средства есть, у других нет и быть не может.

Ну, если средства (пере)определения синтаксиса - это возможность вставит в интерпретатор свой парсер, тогда ой. "myparser myfile.dsl | gcc" - это, конечно, не встроенное средство Си :D

> Тогда я достану собственный боян: НЕ НУЖЕН ВАМ ЛИСП! ПРОТИВОПОКАЗАН!

ААААААААА!!!!!!!! Доктор, я умру, если попытаюсь что-то написать на Лиспе?!!! 8( А от чтения "On Lisp" мне не поплохеет? Может, прекратить?

>> Спорно. зависит от вкуса, не подкреплено примерами.

>Ну опровергни хоть самым маленьким примерчиком... ;)

Здесь пришлось бы снова устраивать соревнование - написать по DSL, и сравнить... Оно того не стоит. И вообще - почему я должен опровергать, а не он - доказывать? ;)

>> ...если имеет синтаксис Лиспа.

>Говорили уже: синтаксис лиспа - это "нечто", имеющее начало и конец.

Вот уж, блин, любители абстракций. Синтаксис Лиспа - это не "нечто", а вполне определенные S-выражения. В синтаксис S-выражений не укладывается ни один из не-Лиспов.

> Ну, если средства (пере)определения синтаксиса - это возможность вставит в интерпретатор свой парсер, тогда ой. "myparser myfile.dsl | gcc" - это, конечно, не встроенное средство Си :D

Определите myfile.dsl, запустите myparser из тела си программы, в которой используется новый синтаксис. Да, и ваш DSL должен владеть всй мощью языка си :)

> Здесь пришлось бы снова устраивать соревнование - написать по DSL, и сравнить...

Урла достаточно. Только с примером, удовлетворяющим условию в предыдущем предложении.

> А от чтения "On Lisp" мне не поплохеет? Может, прекратить?

Ну, если учесть, что время потратите, а пользы не будет - то поплохеет. Но не смертельно. :)Ь

> Синтаксис Лиспа - это не "нечто", а вполне определенные S-выражения. В синтаксис S-выражений не укладывается ни один из не-Лиспов.

S-выражение - это то, что парсер выдаст. А получить он должен это самое "нечто" - достаточно.

>> А от чтения "On Lisp" мне не поплохеет? Может, прекратить?

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

Он уже приносит пользу ;) Мой кругозор расширяется не по часам, а на глазах 8)

> Но не смертельно. :)Ь

Отлегло от сердца :)

Насчет остального - так вы признаете, что и в Лиспе придется писать свой парсер, если "нечто" имеет human-readable синтаксис, а не S-выражения? И если да - то чем это лучше парсера, написанного на Си/Питон/ещечемто (кроме возможности интегрировать его в интерпретатор) ?

> Насчет остального - так вы признаете, что и в Лиспе придется писать свой парсер, если "нечто" имеет human-readable синтаксис, а не S-выражения?

Да. Посмотрите на CLSQL и многочисленные парсеры XML/HTML.

> И если да - то чем это лучше парсера, написанного на Си/Питон/ещечемто (кроме возможности интегрировать его в интерпретатор) ?

Это лечше теми возможностями, которые нам даёт интеграция парсера в интерпретатор/компилятор.

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

А как этим пользоваться и что это даёт - смотрите исходники тех-же CLSQL и парсеров XML/HTML + исходники, например, sbcl, в котором местами на макры код завязан очень сильно.

>> Насчет остального - так вы признаете, что и в Лиспе придется писать свой парсер, если "нечто" имеет human-readable синтаксис, а не S-выражения?

>Да.

Консенсус

>> И если да - то чем это лучше парсера, написанного на Си/Питон/ещечемто (кроме возможности интегрировать его в интерпретатор) ?

>Это лечше теми возможностями, которые нам даёт интеграция парсера в интерпретатор/компилятор.

Тоже консенсус

> Отлично, если вам это "не нужно" (вместе с макрами) - тогда у меня нет больше аргументов.

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

> Мне это на практике не нужно - в ближайшем будущем я на Лиспе программировать не буду. Но хотелось бы понять, как это всё работает. В макры пока не въехал, тем более в их завязки с символьными вычислениями.

Отлично. Читайте книги. Будут вопросы - спрашивайте. На самом деле лисперы очень добрые ;)

P.S. Следующий! :)

> Я хотел сказать "императивному"

А вот с императивным не получится. Ибо тебе придётся вручную управлять памятью, вычислять адрес указателя, использовать циклы и многое другое, чему нет аналогов в естественных языках.

> Были (экспериментальные) языки с настраиваемым синтаксическим анализатором.

Можно создать реализацию лиспа с настраиваемым синтаксическим анализатором. Делов то. Другой вопрос что это нафиг никому не нужно. Ибо ничего лучше лисповского синтаксиса у человечества нет.

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

Как же так? А "копать отсюда и до обеда" - это не описание цикла?

repeat
копать
until обед;

А?

> То, что делал - было не так уж сложно.

В том что ты делал можно было достучаться до любой возможности с?

> .если имеет синтаксис Лиспа.

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

Афигительный диалог:

я: У лиспа идеальный синтаксис для метопрограммирования.

ты: а вот если взять не лисповый синтакси, то буде уже не так идеально.

В общем, ты мне не противоречешь.

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

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

> Другой вопрос что это нафиг никому не нужно.

Это стало ясным лет 30 назад

> Ибо ничего лучше лисповского синтаксиса у человечества нет

Что, совсем ничего? 8-O

> Что, совсем ничего? 8-O

Для макропрограммирования - нет :)

>> То, что делал - было не так уж сложно.

>В том что ты делал можно было достучаться до любой возможности с?

Он транслировался в Си++, и в исходном тексте могли быть Си++-фрагменты. Эти фрагменты, естественно, имели доступ ко всему.

> Афигительный диалог:

> я: У лиспа идеальный синтаксис для метопрограммирования.

> ты: а вот если взять не лисповый синтакси, то буде уже не так идеально.

Там речь шла о DSL, IIRC. Делать DSL, ориентированный на не-лиспера (может, даже не-программиста) - с Лисповым синтаксисом? Благодарю покорно.

> Делать DSL, ориентированный на не-лиспера (может, даже не-программиста) - с Лисповым синтаксисом? Благодарю покорно.

И зря. Кады с автолиспом? :) И, по-мне, лучше бы в школах схему давали, чем паскаль ;)

Это хвостовая рекурсия.

> Это хвостовая рекурсия.

Вернусь домой - нарою точную цитату из Дейкстры, общий смысл - "Ненавижу, бл#, @#$%ов, которые определяют циклы через рекурсию".

> Вернусь домой - нарою точную цитату из Дейкстры, общий смысл - "Ненавижу, бл#, @#$%ов, которые определяют циклы через рекурсию".

Да боян это... Так что можешь не стараться :)

P.S. Надеюсь, ты ни чьи слова "на веру" не берёшь? ;)

> Надеюсь, ты ни чьи слова "на веру" не берёшь? ;)

Перекрестная проверка минимум из двух источников, конечно же. А к чему ты это?

> А к чему ты это?

Я именно про те слова, что сказал Дейкстра ;)