Re[2]: AST-based solution - Философия программирования

AndrewVK wrote:
> R> Сейчас кто-нибудь припомнит R>библиотеку — строк на 1000 —
> производящую полный аккуратный разбор XML в
> R>этот вид (или сам напишет).
>
> Знаешь в чем проблема — в том что это не DSL, для которого такой разбор
> надо написать один раз. Этот формат создается на коленке под конкретную
> задачу и в процессе разработки может неоднократно модифицироваться. И
> что, каждый раз писать эти 1000 строк?
> И опять же — вопрос о валидации так и остался повисшим в воздухе.

Я имею в виду типа схемной. <body><a href="no" /></body> -> (body (a
(properties ("href" "no")))) . И валидирует только XML. Из этого вида мы
видели уже изящные решения (недлинные).

Posted via RSDN NNTP Server 2.0 beta

Здравствуйте, AndrewVK, Вы писали:

E>>Если коротко, то просто подключить несколько генераторов.

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

Придется вводить дискриминатор, если я правильно понимаю, о чем идет речь.

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

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

Так я тебе и не возражал в этом вопросе. Я просто хотел показать, что в отличии от других императивных языков, где для декларативности нужно будет брать XML, в Ruby можно обойтись возможностями самого Ruby. FYI, так сказать.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Один к тебе: а зачем (как используется) тебе эта генерация.

Для решения внутрипрограммных задач кодогенерации. В основном сложный объектных графов. Подробнее о таких задачках описано в документе, ссылку на который приводил ПК (к сожалению там почти ничего нет о том как они решаются) — http://conference2004.kde.org/slides/cornelius.schumacher-metaprogramming.pdf .

ANS>(Кстати, кто-бы дал ссылки на все приведённые решения на всех языках?).
ANS>Но рассмотрим этот файл:

ANS>

ANS>(object "Obj1"
ANS>         (property :name "prop1" :type "int")
ANS>         (property :name "prop2" :type "string"))
ANS>

ANS>Это по сути Lisp-код. Делаем функцию object, делаем функцию property. И запускаем этот код на выполнение. Результат выполнения — вывод кода. Самому парсить ничего не нужно. Что-то в этом духе было?

Вопросы:
1) Валидация исходной схемы?
2) Собственно генерирующий код?
3) Возможность генерации нескольких разных исходников по одной модели?

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, mishaa, Вы писали:

M>Действительно select="/objects/object[@name = $object/extension/@object]" выглядит вполне красиво. Но в обшем вся сила то оказывается в XPath'е,а а не в XSLT как таковом, и именно XPath оказывается самым человеко читаемым куском программы.

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

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, eao197, Вы писали:

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

E>Придется вводить дискриминатор, если я правильно понимаю, о чем идет речь.

И это жопа, потому что структуры того, что нужно генерить могут отличаться кардинально. Вот один из примеров: имеется модель некоего объектного графа. По ней нужно сгенерить
1) Интерфейсную модель на шарпе, представляющую собой API для работы с графом.
2) XSD xml-представления графа.
3) Загрузчик графа из XML.
4) SQL-скрипт для создания таблиц в БД для хранения графа.
5) Загрузчик графа из БД.
6) Реализацию графа, оптимизированную под XPath запросы, но не позволяющую модификацию
7) Реализацию графа, позволяющую модификацию
8) Несколько вспомогательных классов-хелперов, являющихся либо контейнерами с определенной спецификой, либо алгоритмами, работающими с графом.

Ты уже представил себе код на Руби, все это реализующий? А на XSLT это просто несколько шаблонов.

E>Так я тебе и не возражал в этом вопросе. Я просто хотел показать, что в отличии от других императивных языков, где для декларативности нужно будет брать XML, в Ruby можно обойтись возможностями самого Ruby. FYI, так сказать.

Можно. Но вариант на XSLT или функциональном языке все же лучше.

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, raskin, Вы писали:

R>Я имею в виду типа схемной. <body><a href="no" /></body> -> (body (a
R>(properties ("href" "no")))) . И валидирует только XML. Из этого вида мы
R>видели уже изящные решения (недлинные).

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

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, AndrewVK, Вы писали:

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

Такой вопрос: этот граф для всех нижеописанных задач декларативно описывается одним XML?

AVK> По ней нужно сгенерить
AVK>1) Интерфейсную модель на шарпе, представляющую собой API для работы с графом.
AVK>2) XSD xml-представления графа.
AVK>3) Загрузчик графа из XML.
AVK>4) SQL-скрипт для создания таблиц в БД для хранения графа.
AVK>5) Загрузчик графа из БД.
AVK>6) Реализацию графа, оптимизированную под XPath запросы, но не позволяющую модификацию
AVK>7) Реализацию графа, позволяющую модификацию
AVK>8) Несколько вспомогательных классов-хелперов, являющихся либо контейнерами с определенной спецификой, либо алгоритмами, работающими с графом.

AVK>Ты уже представил себе код на Руби, все это реализующий? А на XSLT это просто несколько шаблонов.

От которых ты сам хочешь избавиться

На самом деле я не думаю, что на Ruby будет сложнее, чем на XSLT. Больше по объему -- да, скорее всего. А вот в том, что сложнее и менее сопровождаемее... Но в XSLT я даже не дилетант, поэтому спорить не буду.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Вопросы:
AVK>1) Валидация исходной схемы?
AVK>2) Собственно генерирующий код?
AVK>3) Возможность генерации нескольких разных исходников по одной модели?

Пока я думаю, всё это возможно. При том "малой кровью". Я в вск попробую пример забацать.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>Один к тебе: а зачем (как используется) тебе эта генерация.

AVK>Для решения внутрипрограммных задач кодогенерации. В основном сложный объектных графов. Подробнее о таких задачках описано в документе, ссылку на который приводил ПК (к сожалению там почти ничего нет о том как они решаются)

Думаю, что о том, как они решаются, самую подробную информацию можно найти в SVN KDE:
http://lxr.kde.org/source/kdelibs/kdecore/kconfig_compiler
http://lxr.kde.org/source/kdepim/kode/kxml_compiler/

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Такой вопрос: этот граф для всех нижеописанных задач декларативно описывается одним XML?

Да.

AVK>>Ты уже представил себе код на Руби, все это реализующий? А на XSLT это просто несколько шаблонов.

E>От которых ты сам хочешь избавиться

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

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, AndrewVK, Вы писали:

E>>Такой вопрос: этот граф для всех нижеописанных задач декларативно описывается одним XML?

AVK>Да.

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

AVK>>>Ты уже представил себе код на Руби, все это реализующий? А на XSLT это просто несколько шаблонов.

E>>От которых ты сам хочешь избавиться

AVK>Не то чтобы от шаблонов, но хочется, как всегда, лучшего. Но предлагают пока только худшее.

Наверное те, у кого есть лучшее, просто сидят и молчат, чтобы know-how не раскрывать

Да и я ничего не предлагаю. Просто фантазирую.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, mishaa, Вы писали:

M>Здравствуйте, pvgoran, Вы писали:

P>>Здравствуйте, AndrewVK, Вы писали:

AVK>>>Не для этого xslt создавался. Он создавался прежде всего для генерации html и xsl:fo по xml-файлам с данными. Вобщем понятно — эффективно предложенную задачу на лиспе не решить.

P>>Это еще почему???

M>К чему вопрос?

К невозможности эффективного решения задачи на Лиспе.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, AndrewVK, Вы писали:

P>>Это еще почему???

AVK>Не знаю. Но если пошли отмазки

Т.е. "чувствую, что не решить задачу эффективно, а почему — не знаю"?

... << RSDN@Home 1.1.4 stable rev. 510>>

> S-expression — это список... причем семантика такого списка определяется его первым элементом.

Тут писали про ООП, полиморфимз и пример где-то есть, draw там что-то. Полиморфизм это же семантика по нескольким элементам?

А где-нибудь рассматриваются такие вещи по-подробнее? Если семантика только по одному символу, тут неизбежно должны возникать лишние формальные уровни в деревьях, которые к вычислению отношения не имеют, а лишь более удобны для человека, внимание которого очень ограничено. При компиляции эти формальности должны выбрасываться, на манер inline-подстановок. Получается стандартное представление в виде списков избыточно, хоть его тут и хвалят как самое простое. Даже такая простота может боком выйти. Вот в Рефал такого нет, и поэтому там программы еще короче, чем в Лиспе. Или опять можно на Лиспе сделать полиморфизм лямбда-выражений и получить таким образом Рефал?

Posted via RSDN NNTP Server 1.9

Здравствуйте, pvgoran, Вы писали:

P>Т.е. "чувствую, что не решить задачу эффективно, а почему — не знаю"?

Т.е. пока не увидел, чтобы кто то предложил такое решение.

... << RSDN@Home 1.2.0 alpha rev. 565>>

Здравствуйте, eao197, Вы писали:

Кё>>Мы сможем разве что сравнить синтаксический сахар Ruby `coll do |e|` против (dolist ...) и `puts` против (format ...), что большой информации не даёт

E>Почему же? Для некоторых это может стать причиной выбора в пользу того или иного языка. Например, конструкция "call do |e|" в свое время склонила для меня чашу весов в пользу Ruby, а не Perl-а или Python-а.

Интересно, чем же `coll do |e|` лучше питоновского `for e in coll` ?

Кё>>Куда интереснее сравнить, например, декларацию + трансформер на самом языке (Ruby например), без привлечения XML, и то же самое на Лиспе.

E>Вот чего мы не увидели, так это решение исходной задачи, включая парсинг XML-я, на Lisp-е. А жаль. Но может еще есть надежда?

В том-то и дело, что с Лиспом обычно не нужно привлекать XML и XSLT. Вот например, реализация apply-templates — функция всего в одну страницу.

Вообщем, парсинг XML на Scheme с использованием сторонней библиотеки выглядит так:

(require (lib "ssax.ss" "ssax"))
(print (ssax:xml->sxml (open-input-file (car (vector->list (current-command-line-arguments))) ) `()) )

XML-файл надо передать как первый аргумент этому скрипту (mzscheme.exe -br script.scm arg1). При этом из такого XML

<objects>
    <object name="Obj1">
        <property name="prop1" type="int"/>
        <property name="prop2" type="string"/>
    </object>
</objects>

Генерируется такое s-expr:

(*TOP* 
  (objects 
    (object (@ (name "Obj1")) 
      (property (@ (type "int") (name "prop1"))) 
      (property (@ (type "string") (name "prop2")))
    )
  )
)

Полностью аналогично парсингу на Ruby

Это обращение к библиотеке — при чём тут любой конкретный язык?

Остальное — в понедельник

Или кто-нибудь вперед меня успейте. SSAX лежит тут: http://www196.pair.com/lisovsky/xml/index.html XPath там есть, но думаю он тут будет лишним.

Здравствуйте, ON, Вы писали:

>> S-expression — это список... причем семантика такого списка определяется его первым элементом.

ON>Тут писали про ООП, полиморфимз и пример где-то есть, draw там что-то. Полиморфизм это же семантика по нескольким элементам?

ON>А где-нибудь рассматриваются такие вещи по-подробнее?
ON>Если семантика только по одному символу, тут неизбежно должны возникать лишние формальные уровни в деревьях,
ON>которые к вычислению отношения не имеют, а лишь более удобны для человека, внимание которого очень ограничено.
ON>При компиляции эти формальности должны выбрасываться, на манер inline-подстановок.
ON>Получается стандартное представление в виде списков избыточно, хоть его тут и хвалят как самое простое.
ON>Даже такая простота может боком выйти. Вот в Рефал такого нет, и поэтому там программы еще короче, чем в Лиспе.
ON>Или опять можно на Лиспе сделать полиморфизм лямбда-выражений и получить таким образом Рефал?

На лиспе можно сделать и делаются embedded Prolog (http://www.franz.com/support/tech_corner/prolog-071504.lhtml),
Erlang (http://www.dirkgerrits.com/programming/erlisp/), SQL (http://clsql.b9.com/), HTML (http://www.weitz.de/cl-who/)
— и всё равно это остаётся Лиспом + сохраняет прозрачное взаимодействие / является embeddable по отношению
к Common Lisp. Не вижу никаких препятствий к тому, чтобы эту судьбу мог разделить и Рефал.

Здравствуйте, Кодёнок, Вы писали:

E>>Почему же? Для некоторых это может стать причиной выбора в пользу того или иного языка. Например, конструкция "call do |e|" в свое время склонила для меня чашу весов в пользу Ruby, а не Perl-а или Python-а.

Кё>Интересно, чем же `coll do |e|` лучше питоновского `for e in coll` ?

Тем, что в Питоне выражение 'for e in coll', как я понимаю -- это foreach. А в Руби выражение 'do |e| ... end' -- это блок кода, который можно привязать к большому количество операций. В том числе foreach. Насколько я понимаю в терминологии, 'do |e| ... end' и есть closure. В Питоне, как я помню, это же реализуется через lambda. Но вот в Руби блок кода можно передать параметром в любой метод.

E>>Вот чего мы не увидели, так это решение исходной задачи, включая парсинг XML-я, на Lisp-е. А жаль. Но может еще есть надежда?

Кё>В том-то и дело, что с Лиспом обычно не нужно привлекать XML и XSLT. Вот например, реализация apply-templates — функция всего в одну страницу.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.07.05 10:41
Оценка:

	От:	raskin
	Дата:	15.07.05 10:46
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	15.07.05 10:49
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.07.05 10:51
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	15.07.05 10:51
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	15.07.05 11:10
Оценка:

	От:	Кодёнок
	Дата:	15.07.05 14:11
	Оценка:	1 (1)

От:	VladD2	www.nemerle.org
Дата:	15.07.05 15:44
Оценка: