Здравствуйте, VladD2, Вы писали:
AVK>>а на яке даже выделение многострочных комментариев без включения кода не обходится.
VD>Коментарии еще лексер удаляет. Так что таких проблем у яка нет.
Ну так про лексер и речь. Ах да, ты ж свой написал. ANTLR прекрасно генерит лексер, справляющийся с комментариями без написания кода. Впрочем лексер можно и свой написать.
AVK>> Ну вобщем скачай грамматики и погляди — кусков кода и жутких псевдосимволов с номерами параметров там нет .
VD>Давно скачал. И посмотрел. Что-то мне их граматика еще меньше чем яковская понятна. Возможно с непривычки.
Да нормально вроде. Что конкретно тебя смущает?
VD> Но доки у них фиговые. Я прочел про граматику и мало чего понял. Только общие идеи.
Да нормальные вроде доки,я по крайней мере проблем особых не испытывал. Возможно потому что мне такие грамматики и рекурсивный спуск намного лучше знакомы.
VD>Ты кстати там не нашел толкового туториала или еще чего что можно почитать?
Да там же ссылка есть на jGuru, на фак. В факе море доки. В том числе есть там и раздел типа "я чайник" и в первом вопросе подробнейшим образом рассматриваются азы. Погляди.
VD>Не очень то оно у них стандартное.
Например? (Символы # и ^ можешь просто пока опускать, это управление построением дерева)
VD> Как раз спецификация Шарпа описана практичкски в терминах яка. Только нет "|" и "-" (которые в яке недопустимы).
Не знаю, мне почему то грамматики antlr показались более читабельными. Возможно дело привычки. В общем то синтаксис описания грамматики у них в общих чертах очень похож. Главное различие в способе парсинга.
AVK>>Да чего там ее ставить — запустил инсталлер и нажал ОК. Рантайм поставить не сложно, если он у тебя уже не стоит .
VD>Там 1.1 нужен, а у меня его нет. Надо лезть на Сан...
А ты не в курсе того что JVM обратно совместимы?
AVK>>Набери java в консоли — что будет?
VD>VD>Y:\RSDN\2003-6\Collections>java
VD>'java' is not recognized as an internal or external command,
VD>operable program or batch file.
VD>
VD>
Ну тады качай JRE, это мегов 10.
AVK>>В LL грамматиках сам парсер не конечный автомат, а рекурсивный алгоритм. Т.е. в итоге конечно автомат, как и любая программа, но состояние хранится в стеке вызовов.
VD>Лексер — это 100% НКА/ДКА.
Влад, ты погляди для начала что он генерит, а потом будешь про 100% говорить. Любая программа это 100% конечный автомат, но явно в методе рекурсивного спуска КА не фигурирует. Приведу тебе пример парсера простейщего арифметического выражения. Это грамматика (лексер и опции кодогенератора опущены)
expr
: mexpr (PLUS^ mexpr)* SEMI!
;
mexpr
: atom (STAR^ atom)*
;
atom: INT
;
А это код, который собственно реализует разбор (match выполняет сравнение и сдергивает из потока следующую лексему если совпало).
public void expr() //throws RecognitionException, TokenStreamException
{
try { // for error handling
mexpr();
{ // ( ... )*
for (;;)
{
if ((LA(1)==PLUS))
{
match(PLUS);
mexpr();
}
else
{
goto _loop3_breakloop;
}
}
_loop3_breakloop: ;
} // ( ... )*
match(SEMI);
}
catch (RecognitionException ex)
{
reportError(ex);
consume();
consumeUntil(tokenSet_0_);
}
}
public void mexpr() //throws RecognitionException, TokenStreamException
{
try { // for error handling
atom();
{ // ( ... )*
for (;;)
{
if ((LA(1)==STAR))
{
match(STAR);
atom();
}
else
{
goto _loop6_breakloop;
}
}
_loop6_breakloop: ;
} // ( ... )*
}
catch (RecognitionException ex)
{
reportError(ex);
consume();
consumeUntil(tokenSet_1_);
}
}
public void atom() //throws RecognitionException, TokenStreamException
{
try { // for error handling
match(INT);
}
catch (RecognitionException ex)
{
reportError(ex);
consume();
consumeUntil(tokenSet_2_);
}
}
Где здесь КА?
VD>Да и без разницы стек не стек. Главное, что нужно строить таблицы переходов.
Переходов чего? Состояний? Нет, не нужно.
VD>У мнея лексер вручную написан. Так что тормозить там нечему. Им случаем нельзя его скормить?
Можно, достаточно реализовать этот интерфейс:
public interface TokenStream
{
Token nextToken();
}
Как видишь никаких проблем.
VD>И я не понял, тормоза эти при парсинге или в момент генерации кода парсера?
При парсинге, при первом вызове. Последующие вызовы работают быстро, т.е. это работа статических инициализаторов. Возможно в этом виноват TSQL, у него много ключевых слов.
VD>Джэй работает молниеносно.
Не сам джей, а результат кодогенерации. Вот поэтому я и говорил что возможно рантайм придется доводить до ума. В любом случае если данные статичны значит их можно сразу отсчитать и не считать при каждой заргрузке сборки, явно они где то в рантайме или кодогенераторе накосячили.
AVK>>Да там похоже генератор не рефакторить, а переписыывать надо . Ну и рантайм рефакторить.
VD>Только еще переписывать нехватает. Может тогда уж на яке?
Да на яке тоже проблем хватает. Нет в мире идеала
AVK>>У ANTLR лицензия без каких либо ограничений.
VD>Это большой плюс. Но у джея тоже. Тут вопрос уже в граматике и готовом коде парсера. На них там нет случаем отдельных ограничений?
Не заметил. Да и как можно ограничить использование грамматики?
AVK>>Ну вот например есть событие EnterRule или Error, только оно нигде не вызывается.
VD>Козлы! Вещь однозначно нужная. Хотя наверно это можно и инлайном сделать, прямо в правиле.
Не надо, надо просто немножко подправить кодогенератор. Ты не пугайся, джава не сильно от шарпа отличается
.
VD>Скорее всего не критично.
Точно не критично. С-подобные языки очень хорошо ложатся на рекурсивный спуск.
VD>Хотя у меня к LL-схеме почему-то сразу негативное отношение сложилось. Видимо потому, что для в книжках когда про LL-анализ пишут, все время говорят о проблемах и череззадовом синтаксисе.
Проблемы в основном с сильно отличающимися от С языками.
VD>Мля. Эдак каждый дурак умеет. Даже в Моно и то умнее сделали. Они при входе в тело свойства переключают режим лексера и тот начинает выдавать на get/set соотвествующие ключевые слова.
Знаешь, судя по всему шарповскую грамматику писали не очень профессионально. Грамматика джавы к примеру куда интереснее, но там нет контекстно зависимых ключевых слов.
AVK>>Как это можно сделать еще надо вникать, сразу не скажу.
VD>А дерево он какое строит? Этим процессом можно управлять?
Да. Там в итоге генерятся 3 класса Lexer, Parser и TreeParser. Вот последний как раз и строит дерево, которое задается такими правилами
#(root child1 .. child n)
Причем правила могут быть вложенными. Т.е. дерево в А есть В, а в В есть С описывается так.
#(A #(B C))
VD>Главный вопрос в чем. У нас есть некая конструкция:
VD>[assembly : assembly(assembly ? assembly : assembly)]
VD>и например:
VD>[return : assembly(assembly ? assembly : assembly)]
VD>Так вот парсер должен определить, что в одном месте (в начале первого тэга) assembly — это токен TokAssembly, а в другом, что это идертификатор. Ну, и первую секцию атрибутов он должен определить как глобальную-секцию-атрибутов, а вторую как просто секцию-атрибутов.
По идее TreeParser такое вполне можно разрулить.
... << RSDN@Home 1.1.2 beta 2 (Win32NT 5.1.2600.0) >>
Здравствуйте, VladD2, Вы писали:
VD>Шарп имеет контекстные ключевые слова. Их не много, но это проблема. Первая же проблема возникает при парсинге глобальных атрибутов. Дело в том, что граматика файла в Шарпе выглядит так:
VD>VD>compilation-unit:
VD> using-directivesopt global-attributesopt namespace-member-declarationsopt
[skip]
VD>attribute-arguments:
VD> ( positional-argument-listopt )
VD> ( positional-argument-list , named-argument-list )
VD> ( named-argument-list )
VD>
Влад, а где ты это взял? В смысле грамматику джея для шарпа?
Я вот тут смотрю какой-то файлик аля cs-parser.jay — это оно ?
C Уважением, Andir!
<-- using(RSDN@Home 1.1.2 beta 2) {/* Работаем */} -->
Здравствуйте, Andir, Вы писали:
A>Влад, а где ты это взял? В смысле грамматику джея для шарпа?
A>Я вот тут смотрю какой-то файлик аля cs-parser.jay — это оно ?
Оно
... << RSDN@Home 1.1.2 beta 2 >>
Здравствуйте, VladD2, Вы писали:
L>>Не, лучше C##
VD>Тоже не плохо. Но произностить тяжело. Си шапр шарп — не звучит.
В музыке два диеза заменяются жирным крестиком под названием дубль-диез (𝄪, double sharp)
Здравствуйте, Andir, Вы писали:
A>Влад, а где ты это взял? В смысле грамматику джея для шарпа?
A>Я вот тут смотрю какой-то файлик аля cs-parser.jay — это оно ?
У меня две версии. Один из Моно. Как раз тот что cs-parser.jay. Лругой переписанный мною вариант из крижки ссылку на которую я приводил.
Исползовать Моновскую не охота — так как она гнутая во всех отношениях (главное лицензионно). Да и кривовата. Хотя там прямо в дерево разбор есть.
Могу выложить свою версию (но она конечно далека от завершенности, все элементы есть, но в дерево разбирается пока чуть-чуть).
... << RSDN@Home 1.1.2 beta 1 >>
Здравствуйте, beretta, Вы писали:
B>Я тут вспомнил один примерчик. Скажем у нас есть пользовательский интерфейс, логика предикатов хорошо подходит для решения головоломок. Вот и дать ему головоломку оптимального расположения контролов на форме, так что бы нужное было под рукой и нужного размера, а не нужное где-то в сторонке.
Вот у меня тут с 9 октября валяется следующий ремайндер:
Оптимальный интерфейс
Ставится задача разработать универсальную методику разрабатывать интерфейс к объектной модели.
Предположим, мы умеем отличать "встроенные" объекты от внешних.
Таким образом, объект представляется набором свойств скалярного либо векторного типа (возможностью матричных индексаторов пренебрегаем).
Для каждого типа свойства у нас зарегистрирован соответствующий визуальный редактор, т.е. компонент.
Теперь возникает задача оптимально расположить эти редакторы в ограниченном пространстве.
Пространство комбинаций
Идея в том, чтобы уложить набор редакторов в дерево. Узлами этого дерева являются визуальные контейнеры, а листьями — редакторы. Контейнеры могут быть следующими:
— набор закладок. Отнимает площадь под закладки (чем больше страниц — тем сильнее), но "укладывает" свое содержимое "один под другим"
— горизонтальный набор редакторов
— вертикальное деление на группы
— горизонтальное деление на колонки
Стоит рассмотреть возможность повторного размещения редактора свойства в этом дереве.
Критерии оптимальности
Удобство интерфейса определяется количеством избыточной навигации. Для каждого варианта дерева можно посчитать попарное "расстояние" между любыми двумя свойствами, при этом учитываются
— нажатия Tab
— клики
— скроллинг
Пока неясно, как именно учитывать альтернативную навигацию — например, если брать минимум, то наличие комбинации клавиш, привязанной к редактору свойства, сделает дистанцию до него из любого места равной 1.
Если у нас есть статистика переходов между свойствами (матрица N*N), то ее можно использовать для "взвешивания" попарных расстояний и минимизировать функцию Opt = sum(Dist[i, j]*Freq[i, j]).
В отсутствие статистики переходов можно попытаться
а) оптимизировать дерево, исходя из равноправия переходов. Проблема: очевидно, появится множество вариантов с одинаковой стоимостью.
б) ввести категории свойств, и считать, что переходы чаще всего делаются внутри категории.
... << RSDN@Home 1.1.2 beta 2 >>
The stars so gaily glistened... (Fri, 12 Dec 2003 11:42:11 GMT @529)
...while the fading voice of beretta whispered through the darkness:
b> пикселам. Просто кидаешь блок в какую-то часть диаграмы, а программа уже
b> сама подбирает ей достойное место (в данной части рисунка) и при
b> необходимости перегрупперует остальные элементы.
Какие-то зачатки жэтого вроде в TurboVision были.
Правда там это относилось к однородным элементом типа группа RadioButton
(автоматически подбирались кол-во столбцов и расстояние между), группа
кнопок...
--
If i had ears, i'd heard The Who — Sunrise
http://Arioch.nm.ru/FL/Fidolook_SL.png Mail: the_Arioch<at>nm<dot>ru
Posted via RSDN NNTP Server 1.8 beta