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

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

В лиспе без макр маожно обходится точно так-же, как и в других языках. Вот как другие языки без них обходятся - не знаю ;)

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

Ну, чуть по-больше: посмотри в sbcl реализацию external-format для потоков и строк

> Да, psyco cъест _любой_ питоний код, не любой ускорит, но _съест_ _любой_.

О, это уже кое-что ;) И давно это он так? Ладно, на досуге гляну.

> Врешь. *ML уж точно во многих областях (type inference, pattern matching) лиспа опередил уже десять лет назад.

Ага. Крик "Макры!" и эхом "CLOS! CLOS. CLOS..." ;)

>При использовании Numeric Python мне не надо возиться с FFI. Вы >вообще видели Numeric?

Да и к тому же специально для рассчетов Lush есть, кроме того, что он вероятно самый скорострельный из Лиспов (свободно можно писать код ворочающий любые матрицы и это будет работать так же шустро как в Си), он позволяет примешивать в любой пропорции сишный код прямо в текст на Лиспе, имеет готовые баиндинги ко всяким математическим (и не только) либам. Не так толст, как реализации CL. У него есть баиндинги к GUI библиотекам и SDL.

> Да, но "метапрограммирование ненужно". В том смысле, что эти проблемы решает малое количество людей один раз, и, в любом случае, проектирование DSL - сильно более сложная задача, чем его реализация (даже на С/yacc).

Ну а если DSL уже спроектирован? Благодаря этому топику сейчас исследую возможности генерации парсеров. То есть, в оригинале стояла задача некого обработчика (PL/)SQL. Одна лишь пустая грамматика, реализованная только на 2/3 на Эйфеле занимает порядка 10000 строк. Причем, больше половины правил -- это стандартная обработка списков с вариациями. Имена правил тоже однотипны, например, если есть правило reference, то почти наверняка нужны правила optional_reference, list_of_references и optional_list_of_field_references, первое -- для пропуска имени поля по умолчанию, второй и третий -- для (непустого и пустого) списков полей.

Далее, примерно 10%-ное заполнение действий для грамматики уже увеличило код до 14000 строк. При этом, например, в каждом правиле необходима стандартная обвязка типа if not <options.parse_only> then <действие> end. Кроме того, например, для списков, стандартное действие -- begin $$ := $1 $$.put_last($2) end. Прибавьте к этому жесткую типизацию правил, поэтому иногда приходится тыкать что-то вроде begin $$ := compound($1) $$.put_last($2) end, где в compound обернут кастинг типов и генерация объектов по нулевым ссылкам. Аналогичная история и с лексером, где во всех случаях разбора нужно выполнить один и тот же процедурный суффикс.

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

В общем, есть задняя мысль, что можно реализовать некую "ядерную" часть грамматики (предполагаю, что это 10-15% всего кода), из которой потом разворачивать полную (пусть даже и с лишними правилами), а для нее по неким шаблонам генерировать основные действия. Лет 5 назад, когда первый раз решал эту задачу (тогда для VHDL/Verilog), была идея реализовать что-то вроде YAGA/YAGG (Yet Another Grammar Analyzer/Generator), но когда понял, что на lex/yacc придется писать анализатор грамматики самого lex/yacc, возникло ощущение некого онан^Wдекаданса -- написание парсера ради парсеров. Сейчас есть идея свернуть SQL-грамматику в Лисп, а с него сгенерировать Эйфель-заточенное описание на Lex/Yacc. То есть, получаем хороший пример метапрограммирования (тут, кажется, кто-то хотел?), где целевой язык -- Lex/Yac/Eiffel, а последнее уже уходит в кроссплатформенный C. Впрочем, если заведется ecl, то и Эйфель можно будет выкинуть. Возможно, это и станет ядром YAGA.

Подозреваю, что у бугмакера процесс написания прог на С примерно так и организован?

> Ну, вон, гтк к sbcl у кого-то тут подцепить не получилось.

Справедливости ради стоит сказать, что таки получилось. Хотя, конечно, пока в стиле 1:1 и после некоторых плясок с бубном. Но запустить clsql по образцу оказалось уже проще.

Кстати, приятно удивляет размер биндингов. Например, ядро clsql -- всего несколько сотен строк кода, а проблемное место (нашел-таки багу в ем) нашел сразу простым поиском. Общую структуру понял примерно минут за пять, хотя боюсь, что как для новичка без трейсера не разобраться. Пожалуй, самой большой проблемой будет поиск авторов для включения патча в основную ветку.

Интересно, сколько в исходниках занимает ядро алхимии? В свое время пытался читать PyGTK (чтобы понять недокументированные возможности), быстро обломался.

> А, скажем, к какому-нибудь cairo их вообще нету, небось.

http://cairographics.org/cl_2dcairo

Правда, я его и в Питоне не юзал. Бо не знаю, для чего оно...

> специально для рассчетов Lush есть

Коммерческий?

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

После твоих достижений в освоении лиспа это даже читать смешно ;)

http://clsql.b9.com/ далее через мэйл-лист

> > специально для рассчетов Lush есть

> Коммерческий?

Не мужыки, вы добиваете... Это же один запрос к гуглу

http://lush.sourceforge.net/

> дык он оперативу освобождает ужо?

ДА! В 99.99999% случаев. Приведи реальный пример этих 0.00001%, когда он не освобождает память и это может привести к проблемам.

Сможешь привести пример, хорошо, если нет, то завязывай с этими воплями про память.

> ДА! В 99.99999% случаев.

согласишся ли ты юзать бучную батарейку, которая в 99.99999% случаев работает нормально а в оставшиеся взрываецо и жжыгает тебе йайтса?

> Приведи реальный пример этих 0.00001%, когда он не освобождает память и это может привести к проблемам.

там гдето выше я ссыло давал.

> Любой большой программный комплекс - сложен по определению.

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

> А в языках с "настоящими" GC разрушение a и b произойдет неизвестно когда, и в непонятном порядке.

Я ж так и написал: вызывайте финализатор явно и будет Вам щасте. Если имеется ввиду, что сборщик мусора без Вашего ведома соберет объекты, дыкть, не теряйте на них ссылки и всего делов. Или в С/C++ утечка памяти менее страшна, чем непредсказуемая финализация?

> Соотвественно, заявление что

>> " В Эйфеле все exception являются safe."

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

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

Так что, все Ваши проблемы вполне решаются и в Эйфеле и в Питоне. Разница в том, что в этих языках нужно прикладывать дополнительные усилия, чтобы организовать синхронную финализацию, в то время, как в С++ приходится тратить силы, чтобы организовать асинхронную. В моем опыте случаев первого типа раз в 1000 больше, чем второго (если честно, мне ни разу не пришлось контролировать финализацию, все требуемые случаи, например, с файлами и другими объектами ОС, знаю только по учебникам). Возможно, это различие в круге решаемых задач.

Кстати, если область решаемых задач узко заточена под СМО, то почему не используется Эрланг? У самого до него руки не дошли, но судя по отзывам -- самое оно для таких систем. Не знаю, как там обстоят дела с GC. Может, Вам подойдет?

>Коммерческий?

Нет, не коммерческий и Open Source. Ссылка только что выше была.

> ECL? Но там много ещё чего "пилить" надо. Хотя может то, что надо "пилить", вам и не нужно. Смотрели?

Буду посмотреть.

>> Но вот можно ли быстро и элегантно генерить кроссплатформенный С-код из лисповских программ?

> GCC?

А шо GCC? Умеет из лиспа на входе получить С на выходе?

>> А было бы вкусно.

> Не было бы вкусно. Ибо потеряли бы как раз много лисповых вкусностей. (К примеру, у того-же ECL не _любой_ код, который нормально компилируется, может выполниться в REPL :( А так может когда-нибудь и будет такая возможность.

И это плохо :-(. Похоже, пока потренируюсь с промежуточным решением на Эйфеле.

> Или берите коммерческие версии.

На Just for fun не хочется тратить свои кровные. Лучше новый наладонник за те же деньги куплю.

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

Прикольно. Только у меня предложение. Не через консоль, а через TCP/IP, т.е. есть сервер с сотоянием мира, к нему по TCP/IP цепляется клиент и получает карту мира в какой-либо форме, посылает комманду и получает в ответ новое состояние мира.

Таким образом можно будет сделать клиента просто с выводом в stdout, c curses и даже с GUI или с веб-мордой :-)

Команды это передвижение и взять / положить. Игра заканчивается когда все предметы лежат на выходе.

В зачёт идёт код сервака, человеческого клиента и код бота.

Человеческий клиент в зачёте с выводом в stdout

Lisper-ы, ну как?

Может вообще устроить LOR language shootout?

Только сразу условие, если победит не лисп, то вы прекратите распространять FUD про другие языки, OK?

> когда первый раз решал эту задачу (тогда для VHDL/Verilog)

А если не секрет, то что вы с VHDL делали?

> Интересно, сколько в исходниках занимает ядро алхимии?

    653 ./sqlalchemy/ansisql.py
    519 ./sqlalchemy/attributes.py
    271 ./sqlalchemy/databases/firebird.py
    183 ./sqlalchemy/databases/information_schema.py
    492 ./sqlalchemy/databases/mssql.py
    292 ./sqlalchemy/databases/mysql.py
    337 ./sqlalchemy/databases/oracle.py
    374 ./sqlalchemy/databases/postgres.py
    280 ./sqlalchemy/databases/sqlite.py
      8 ./sqlalchemy/databases/__init__.py
    878 ./sqlalchemy/engine.py
     43 ./sqlalchemy/exceptions.py
    192 ./sqlalchemy/ext/activemapper.py
    121 ./sqlalchemy/ext/proxy.py
    182 ./sqlalchemy/ext/sqlsoup.py
      1 ./sqlalchemy/ext/__init__.py
    979 ./sqlalchemy/mapping/mapper.py
    359 ./sqlalchemy/mapping/objectstore.py
    980 ./sqlalchemy/mapping/properties.py
    275 ./sqlalchemy/mapping/query.py
    129 ./sqlalchemy/mapping/sync.py
    348 ./sqlalchemy/mapping/topological.py
    857 ./sqlalchemy/mapping/unitofwork.py
     31 ./sqlalchemy/mapping/util.py
    174 ./sqlalchemy/mapping/__init__.py
     86 ./sqlalchemy/mods/selectresults.py
      6 ./sqlalchemy/mods/__init__.py
    296 ./sqlalchemy/pool.py
    644 ./sqlalchemy/schema.py
   1491 ./sqlalchemy/sql.py
    202 ./sqlalchemy/types.py
    468 ./sqlalchemy/util.py
     22 ./sqlalchemy/__init__.py
  12173 total

Но решает то она обратную задачу, не парсить SQL, а генерировать его

> Нет, не коммерческий и Open Source. Ссылка только что выше была.

Не нашел ссылку :-(. Можно еще раз?

Ага, наш топик, открытый целиком, уже валит CMS ЛОРа (java.lang.OutOfMemoryError). Я им отписал, так что ждите, щас модераторы заявятся. ;-)

> там гдето выше я ссыло давал.

Аффтар той телеги мудак. Проблема надуманная и её не существует, в кратце суть его проблемы "питон плахой бууу, сделал бобу маленькому праграмисту, ааааа"

Приведи свой пример.

>> Да, psyco cъест _любой_ питоний код, не любой ускорит, но _съест_ _любой_.

> О, это уже кое-что ;) И давно это он так? Ладно, на досуге гляну.

Давно. Хуже того проект полностью стабилен, т.е. у автора нет ничего в TODO и нет открытых багов.

> Приведи реальный пример этих 0.00001%, когда он не освобождает память и это может привести к проблемам.

Чаще, чем ожидается. Я закинул этот пример в PythAgora. Тема вызвала интерес, например,

> интересно наблюдать на примере pyGTK работу сборщика мусора, когда есть 20 TreeView в них выводится содержимое файла и память разрастается до 200мб, после чего делаем очистку послей-память ~140mb, через минуты 2-3 память = 8 мб =) интересно бы почитать о принципах работы gc в питоне.

Задачю я всё ещё недопонял.

> Только сразу условие, если победит не лисп, то вы прекратите распространять FUD про другие языки, OK?

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

> Не нашел ссылку :-(. Можно еще раз?

Упс. Уже нашел :-(.

> А если не секрет, то что вы с VHDL делали?

Ну конкретно в тот момент это был генератор VHDL-описания аппаратных приблуд в промежуточный формат для дальнейшего синтеза/симуляции.

> Но решает то она обратную задачу, не парсить SQL, а генерировать его

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

> Я например активно юзаю собтвенноручно сгенеренные баиндинги к OpenCV

Я работал с OpenCV года полтора назад и юзал питоновские байнидинги, которые шил в комплекте, но потом обнаружилось что байндинги не полные и вряд-ли когда будут полные, т.к. в C API они предлагали использовать касты и пойнтерную фрифметику, и для бедного SWIG-а это было через чур.

Ты не сталкивался с такой проблемой? И как с ней боролся?

> А шо GCC? Умеет из лиспа на входе получить С на выходе?

Зыть, опечатка - GCL имелся в виду

В любом случае - и ECL и GCL будут генерить код с "поправкой на ветер", т.е. с опорой на своё ядро. Делать из этого бинари - запросто, а вот использовать отдельно - врядли. Или такая задача не ставилась?

> И это плохо :-(. Похоже, пока потренируюсь с промежуточным решением на Эйфеле.

Ну, ты сам себе хозяин. Но ECL посмотри - неплох. Да, Lush я пока не ковырял - ничего сказать не могу.

> Прикольно. Только у меня предложение. Не через консоль, а через TCP/IP, т.е. есть сервер с сотоянием мира, к нему по TCP/IP цепляется клиент и получает карту мира в какой-либо форме, посылает комманду и получает в ответ новое состояние мира.

Угу. А если правила еще чуток усложнить, то получится Space Trek (Космический Лабиринт), в который мы баловались в пору нашей олимпиадной юности :-).

> На Just for fun не хочется тратить свои кровные. Лучше новый наладонник за те же деньги куплю.

А их там тем или иным способом можно использовать бесконечно. Хотя конечно - ну его... :)

>Lisper-ы, ну как?

А прикольная мысля. Только бот надо чтоб на сервер закачивался и задачу там автономно решал, команды бота на спец. DSL пишутся, сервер и язык наращивается прямо на ходу, т.е. перезапускать сервер нельзя. Текущие параметры бота отображаются через TCP/IP на консольном клиенте в любом удобном виде. У кого бот будет шустрее решать задачу и в языке для бота будет больше возможностей, тот победил.

>Только сразу условие, если победит не лисп, то вы прекратите >распространять FUD про другие языки, OK?

ОК. Аналогичная просьба нелюбителям Лиспа.

> Только сразу условие, если победит не лисп, то вы прекратите распространять FUD про другие языки, OK?

"Стоять, Зорька!" Т.е. наши ответы на ваши вопросы "А чем лисп лучше XYZ? А я могу вот так да вот так - а вы что можете? А я не знаю - нафиг мне это ннадо?" - это FUD про другие языки? Зыть, где выход - вы знаете...

Точнее: текущие параметры бота, лабиринта, прогресс в решении задачи выноса вещей отображаются на клиенте (сойдет и консольный, но можно и c GUI). Еще можно добавить, чтобы сервер при обновлении обновлял на клиенте представление параметров (т.е. обновлял сразу клиента до нужной версии) и чтобы документацию по текущей версии DSL с сервера можно было получить при подключении или в ходе работы.

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

Может достаточно "изменений в мире"? А то весь мир может быть довольно большим.

> Команды это передвижение и взять / положить. Игра заканчивается когда все предметы лежат на выходе.

Ещё: мир трёхмерен; у бота/игрока нет карты (но у бота может быть память), дальность видимости задаётся; лабиринт не идеальный - т.е. используя только правило левой/правой руки его не обойти...

> В зачёт идёт код сервака, человеческого клиента и код бота.

А ещё генерация лабиринтов и распределение вещей в (псевдо-)случайном порядке.

> Lisper-ы, ну как?

Гы-гы, только после вас ;)

>Ты не сталкивался с такой проблемой? И как с ней боролся?

Нет, не было никаких сложностей. Я в препроцессор Lispworks кинул его заголовки и сразу получил баиндинги практически на всю библиотеку. Правда часть функционала я все таки руками довожу, чтобы было получше с Лиспом интегрировано, всякие там финалайзеры на объекты, енумераторы удобные и т.п. в итоге получается нечто вроде спец. языка для отслеживания объектов в реальном времени:

(with-objects (x y angle size) (map-ellipses my-image) ;; делаем что-то с координатами углом наклона и размером ;; очередного эллипса t) ;; вернуть t для продолжения перечисления, nil для завершения

Блин про форматирование снова забыл :-(

(with-objects (x y angle size) (map-ellipses my-image) 
       ;; делаем что-то с координатами углом наклона и размером 
       ;; очередного эллипса 
t) ;; вернуть t для продолжения перечисления, nil для завершения 

>Ещё: мир трёхмерен; у бота/игрока нет карты (но у бота может быть >память), дальность видимости задаётся; лабиринт не идеальный - т.е. >используя только правило левой/правой руки его не обойти...

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

>> там гдето выше я ссыло давал.

> Аффтар той телеги мудак. Проблема надуманная и её не существует, в кратце суть его проблемы "питон плахой бууу, сделал бобу маленькому праграмисту, ааааа"

> Приведи свой пример.

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

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

Вместо 3D к вышеперечисленным вещам лучше добавить, что язык для бота должен позволять ему генерировать программы для самого себя и исполнять, например можно эволюционно совершенствующийся бот создать или reinforcеment learning заложить. Опционально реализовать сообщества ботов, т.е. чтобы несколько штук по лабиринту ходили и помогали друг другу совершенствоваться.

Хватит пожалуй ;-)

Угу. Можно и без 3D. Только это - боту/игроку поступает не инфа о всём мире, а только видимая область - и передавать много не надо, и боты-ясновидящие в пролёте ;)

Естественно, что код для бота должен быть безопасным в смысле, что он напрочь должен быть отрезан от файловой системы, сети и т.д., должен быть только интерфейс для общения с движком лабиринта и может быть для выдачи каких-то отладочных сообщений на клиента и обратно.

>Угу. Можно и без 3D. Только это - боту/игроку поступает не инфа о >всём мире, а только видимая область - и передавать много не надо, и >боты-ясновидящие в пролёте ;)

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

Прикольно. В языке бота сразу же будут доступны все управляющие конструкции Лиспа + макросы, т.е. почти весь Лисп (даже CLOS) за исключением IO, многопоточности и т.п.

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

> Это ты врёш, и сильно. Есь gcl.

gcl уже реализовал ANSI Common Lisp?

>Да и с лиспом лиспопроги подключаются как misc_binaries ещё легче.

Это правда только для тех программ, которые можно пондять из core каким-то стандартным eval-ом с командной строки. Для Java инвокация стандартизована, для CL - нет.

> Ты просто рассуждаеш о вещах о которых не имееш ни малейшево представления.

Ну, как и ты ;)

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

Врешь. Список - да, хеш - нет. И вообще, список - это не совсем уж "примитивный" тип. Примитивный - это символ и cons cell.

А если брать стандартную библиотеку - то у C++ она, как минимум, не беднее. Хешей там нету, правда - только упорядоченные ассоциативные контейнеры - но это и ни разу не "кучи байтов".

> Если для большинства лисппрог новых типов строить безсмысленно, то на с/с++/питоне для более-менее сложной задачи с этого и приходицо начинать, изобретая лисапет сново и сново.

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

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

Нет. adventure видел?

в духе (строки, начинающиеся на ":" - приглашение "игры", остальное - ввод пользователя):

:nothing here :you may go south :you may go west west :you wen west :Item_A lies here :you may go east :you may go west north :you hit the wall :Item_A lies here :you may go east :you may go west take Item_A :you are full :Item_A lies here :you may go east :you may go west drop :you dropped Item_B :Item_B lies here :Item_A lies here :you may go east :you may go west pick Item_A :you picked up Item_A :Item_B lies here :you may go east :you may go west

Ну и так далее. Парсить подобный вывод - несложно, командовать такой прогой - тоже.

> > Врешь. *ML уж точно во многих областях (type inference, pattern matching) лиспа опередил уже десять лет назад.

> Ага. Крик "Макры!" и эхом "CLOS! CLOS. CLOS..." ;)

type inference для примитивных типов на макрах, с реализацией generic алгоритмов? Ню-ню. Это разве вообще возможно?

CLOS в качестве замены pattern matching в Haskell/OCaml? НТам можно специализировать генерик на константу? Можно сказать "для пустых списков - так, для единичной длины - сяк, для более длинных - эдак"?

А покажи, я, может, передумаю.

> > Да, но "метапрограммирование ненужно". В том смысле, что эти проблемы решает малое количество людей один раз, и, в любом случае, проектирование DSL - сильно более сложная задача, чем его реализация (даже на С/yacc).

> Ну а если DSL уже спроектирован? Благодаря этому топику сейчас исследую возможности генерации парсеров. То есть, в оригинале стояла задача некого обработчика (PL/)SQL.

[skip lots of handwaving]

Если я ничего не путаю, для ANTLR есть готовая грамматика SQL92. Пускай он вам parse tree сделает, и уже из него генерите, что хотите, "деревянными" трансформациями (опустились до листьев сверху, наренерили наследуемых атрибутов, поднялись обратно - собрали вычисляемые).

> Я ж так и написал: вызывайте финализатор явно и будет Вам щасте.

Не будет. Я не хочу "вызывать финализатор явно", я хочу стековой дисциплины. Дабы вереницу try/catch не городить (а иначе довольно трудно вызвать финализатор, словив исключение уровней так на пять выше)ю

> Если имеется ввиду, что сборщик мусора без Вашего ведома соберет объекты,

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

Поэтому финализаторы в garbage-collected языках, имхо, абсолютно бесполезны - привязывать к ним "счетно-конечные" ресурсы бесполезно по перечисленным выше причинам, а пямять - ну, она и так освободится. Разве что деаллокацию FFI-объектов можно делать - да и то только если их не конечный пул.

Ну вы блин демагогии развели из примитивного предложения написать кастрированный клон adventure и A* pathfinder.

> Прикольно. В языке бота сразу же будут доступны все управляющие конструкции Лиспа + макросы, т.е. почти весь Лисп (даже CLOS) за исключением IO, многопоточности и т.п.

вовсе нет, с чево бы? При желании можно но луче не надо.

>> Это ты врёш, и сильно. Есь gcl.

> gcl уже реализовал ANSI Common Lisp?

не. а gcj полностью совместимый с саньей жабой?

>> Да и с лиспом лиспопроги подключаются как misc_binaries ещё легче.

> Это правда только для тех программ, которые можно пондять из core каким-то стандартным eval-ом с командной строки. Для Java инвокация стандартизована, для CL - нет.

http://www.cons.org/cmucl/doc/executable.html

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

>> Ты просто рассуждаеш о вещах о которых не имееш ни малейшево представления.

> Ну, как и ты ;)

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

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

> Врешь. Список - да, хеш - нет.

не, эт ты врёш. Смотри в стандарте чё пишут http://www.lisp.org/HyperSpec/Body/chap-18.html

> И вообще, список - это не совсем уж "примитивный" тип. Примитивный - это символ и cons cell.

ну уж какой есь. Может быть следовало сказать "встроенный" но поскольку он всёодно не построен средствами лиспа из остальных ево типов, можно сказать чё и примитивный тоже, да. А в сях полюбому ево нужно делать вручную из структурок/укозателей/массивов/всево прочево. В питонос++ тоже. Хоть там кирпичики покрупнее, но средствами языка настолько же неудобно с ними, списками, там работать ибо непредназначены.

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

> Нет. adventure видел?

> в духе (строки, начинающиеся на ":" - приглашение "игры", остальное - ввод пользователя):

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