Tree Transformation Language

[Володимир Лісівка]

TXL (Tree TRANSformation Language)  - це мова спеціально призначена для трансформації структурованих документів, таких наприкад як програми. За ідеєю вона подібна до функціональної мови XSLT і так само має два основних елементи - опис граматики вхідної мови і опис правил для трансформації. Нажаль реалізація TXL не вільна, але доступна для вільного завантаження в тому числі і під Лінукс. Цікавим є також пропонований метод навчання - автори пропонують розв’язати чотири завдання та відіслати їх на розгляд Оракула (ментора): http://www.txl.ca/nchallenge.html . Автори рекомендують використовувати TXL для розв’язування власних задач тільки коли ваші розв’язки пройдуть перевірку. :-)

Домашня сторінка: http://www.txl.ca/

[Re.]

На жаль, ех, на жаль.

[Володимир Лісівка]

Теоретично, коли допиляють Perl6, то на ньому можна теж буде можливо описувати граматики і робити перетворення.

[msorc]

Задум з завданнями та оракулами дійсно гарний. Дисциплінує освоєння інструменту та дозволяє не витрачати час на новачків з простими питаннями.
Автор обіцяв скоро відкрити реалізацію. Може навіть цього літа.
TXL від інших засобів на мою думку відрізняється тим, що немає потреби коцентруватися на побудові парсерів та виводу отриманого дерева (pretty printing), тільки на правилах трансформації.
Нещодавно я робив трансформації з Java у Tcl та Python (є на сторінці прикладів). Ось так може виглядати кінцевий результат: tcl, python.

[Володимир Лісівка]

Відразу бачу, що наприклад типове значення "null" в Яві перетворилося в порожній рядок в Tcl, тобто парадигми Яви і Тикля не співпадають. Хотілося б побачити реальний приклад - якийсь код з тестами і результат виконання цих тестів. Відчуваю що відразу вилізе проблема базової бібліотеки. :-)

[msorc]

Ява та Тікль досить різні мови й звісно, що деякі сутності неможливо перекласти один до одного.
Деякі конструкції можуть не мати сенсу в іншій мові або синтаксично відображатися зовсім інакше. Тому й застосовуються різні спрощення.
Проблема базової бібліотеки спливає майже завжди. Її можна вирішувати двома засобами:

• Переклад базової бібліотеки у цільову мову (наприклад перекласти JDK->Python)
• Заміна базових класів(функцій) початкової мови аналогами цільової

Вибір залежить від багатьох параметрів.

А що саме хотілося б потестувати?
Реальних прикладів у вільному доступі я не бачив. Автор TXL казав про успішні комерційні проекти з мільйонами строк коду.
Ще хочу сказати, що використання таких засобів, як TXL, не обмежується тільки трансформацією між мовами. Можна робити досить цікаві речі с текстами програм - витягувати різні статистичні дані, знаходити використання певних конструкцій та інше.

[Володимир Лісівка]

А що саме хотілося б потестувати?

Значно краще було б, якби можна було відразу оцінити ступінь ушкодження програми після трансформації. Так візуально програми подібні, але скільки у них помилок після трансформації - сказати сходу важко.

Ще хочу сказати, що використання таких засобів, як TXL, не обмежується тільки трансформацією між мовами. Можна робити досить цікаві речі с текстами програм - витягувати різні статистичні дані, знаходити використання певних конструкцій та інше.

Можна трансформувати опис об’єктів якогось протоколу, щоб вони мали одинаковий інтерфейс у всіх мовах.

Мені от цікаво, чи робити трансформацію між українською мовою та мовами програмування? Ніби ще в 1993-му зробили парсер української мови (досить маленький - 18кб, здається). Він аналізував слова пробуючи розбити слово на префікси, корені, та суфікси. Алгоритм там був дуже простий, щось типу "беремо спочатку суфікс найбільшої довжини, який підходить, і перевіряємо на відомі корені і префікси, якщо не підходить - беремо суфікс меншої довжини", тобто банальний пошук по дереву. Теоретично, для цього можна написати і формальну граматику (конфлікти звичайно будуть). Чи зможе TXL працювати з такою граматикою?

[msorc]

Значно краще було б, якби можна було відразу оцінити ступінь ушкодження програми після трансформації. Так візуально програми подібні, але скільки у них помилок після трансформації - сказати сходу важко.

Зрозуміло. Це можна оцінити тільки на реальній задачі та якщо наявні тести для початкового коду. Але це буде оцінка конкретного набору правил трансформації, а не TXL взагалі.

Мені от цікаво, чи робити трансформацію між українською мовою та мовами програмування? Ніби ще в 1993-му зробили парсер української мови (досить маленький - 18кб, здається). Він аналізував слова пробуючи розбити слово на префікси, корені, та суфікси. Алгоритм там був дуже простий, щось типу "беремо спочатку суфікс найбільшої довжини, який підходить, і перевіряємо на відомі корені і префікси, якщо не підходить - беремо суфікс меншої довжини", тобто банальний пошук по дереву. Теоретично, для цього можна написати і формальну граматику (конфлікти звичайно будуть). Чи зможе TXL працювати з такою граматикою?

Можна спитати у авторів, бо я можу помилятися, мені здається що ні. Я б розбивав слова іншими спеціальними засобами, а результати подавав до TXL-програми.
Тут треба дивитися на задачу взагалі, може TXL і не потрібен.

[Володимир Лісівка]

Можна спитати у авторів, бо я можу помилятися, мені здається що ні. Я б розбивав слова іншими спеціальними засобами, а результати подавав до TXL-програми.
Тут треба дивитися на задачу взагалі, може TXL і не потрібен.

Задача проста - розбирати українську мову. Англійська мова дуже складна для розбору, тому придумують якийсь підмножину, яка не має двозначностей, називають її мовою програмування і використовують її. Українська мова достатньо однозначна для того, щоб написати один парсер на всі випадки життя (приблизно як парсер для XML).

[msorc]

Мені таки здається що краще брати спеціальни засоби для розбору природних мов, засоби для мов программування можуть не підійти.