c-smile wrote: > VD>Единственное что я не понимаю, так это зачем ты делешь раелизацию > ЯваСкрипта не совместимую со стандартом? Тогда уж лучше бы просто > включил в свой продукт вместо него тот же Руби. > Зверек, бедолга, пытается сию трепетную лань оплодотворить как-то... у > него есть htmlayout c ruby скрещенный.
А ты не собираешься распространять htmlayout в исходниках? Под
коммерческой лицензией (да хоть и под NDA).
Здравствуйте, Зверёк Харьковский, Вы писали:
CS>>[4,3,2,1].sort( |l,r| l<r );
ЗХ>Педантизма ради. В Ruby это будет выглядеть так: ЗХ>[4,3,2,1].sort { |l,r| l<r }
Pardon moi. Облажался. Правильный вариант вот таков, конечно же:
[4,3,2,1].sort { |l,r| l<=>r }
Здравствуйте, c-smile, Вы писали:
CS>Наверное. Хотя вот я уже второй язык написал. О чем-то да могу судить?
Не знаю, не знаю. Оценки быстрадействия явно не верные.
CS>Вот еще написал XML scanner со скоростью обработки 40mb XML в секунду (на codeproject).
Это. Меня пенисометрия не возбуждает.
CS>>>[4,3,2,1].sort( |l,r| l<r );
VD>>Еще раз. Лишняя собака. У Руби я что-то не замечаю собаки перед |. Хотя почти уверен, что в Руби | так же используется как знак "или".
CS>А если подумать?
Кто же тебе может помешать это сделать?
CS>Такой роскоши как AST у меня нет.
Твои проблемы но это тут не причем. Не АСТ, так стек.
CS>В момент когда я встретил ')' у меня уже все выражение странслированно в байткод.
Интересно, а приоритеты операторов ты как разруливаешь? Или тоже если встретился второй операнд, то ты сразу байткод порождаешь... даже если дальше идет умножение, а распознано сложение?
CS>Т.е. в момент появления открывающей '(' : CS>а) я четко знаю что мне парсить — список параметров или выражение
И по фигу что внутри? Очень странно.
CS>б) в случае ошибки входного синтакиса я могу однозначно сказать в чем она.
Хм. Другие тоже могут.
CS>в) мне не нужен AST в чистом виде — AST это память объема неизвестного заранее и время на его обработку.
Не нужен, так не нужен. Кто же заставляет. Хотя с АСТ жить конечно проще, но можно и без него.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
K>>Для любого NFA найдётся эквивалентный ему DFA (в смысле, допускающий ту же регулярную грамматику). GZ>Безусловно. Многие регуляры так работают. Но только в этом случае есть некоторая неприятная оссобенность. Для n состояний NFA в худшем случае можно получить 2^^n состояний DFA. А соответсвенно не всегда данная задача разрешима. Поэтому парсеры с расширенными возможностями работают сразу в NFA.
Ну и сколько же времени тратят они с NFA? Каким образом клонируют кучу состояний?
Худший случай с 2 ^ n состояниями весьма непросто получить. Это надо специальный пример писать. ДЛя обычных языков как правило ДКА не сильно разбухает по сравнению с НКА.
Здравствуйте, vdimas, Вы писали:
V>JScript входит в поставку .Net. Полностью готовый и удобный скрипт-енжин. Очень удобно настраивать окружение скриптов, т.е. выставлять т.н. "глобальные" объекты. Напрямую можно использовать .Net-объекты и т.д. В этом плане я не вижу преимуществ Питона, скорее наоборот.
Э-э-э... Питон посимпатичнее будет. JS не очень красивый.
K>>Это была шутка. Конечно же, Лисп мощнее, но не всякий смирится с (write (+ a b)).
V>если это выражение верхнего уровня, то оно выглядит чуть проще: V>
V>print (+ a b)
V>
V>
Это смотря где.
K>>Как языки — да (хотя по поводу Python'а можно поспорить). Для решения конкретной задачи они подходят лучше. Вообще, неразумно для решения всех задач использовать один мегаязык. Лучше использовать несколько языков, каждый для решения определённого класса задач. Хотелось бы, чтобы между ними можно было без проблем наладить взаимодейсвие.
V>Я потому и предлагал JScript.Net с т.з. организации взаимодействия со всем остальным. Ты говоришь, что потратили человеко-месяц на прикручивание Питона? В этом случае вы бы потралили пару человекодней.
Во-первых, никто ещё не тратил времени, только собираемся. Во-вторых, нужно тщательно перелопатить объектную модель отчётов. В-третьих, нужно сделать поддержку клиентских скриптов. В-четвёртых, ожидается общая поддержка скриптов, а там уже будут реализации. Просто реализацией по-умолчанию решили выбрать реализацию Питона.
Здравствуйте, VladD2, Вы писали:
VD>А какие тут проблемы? Вон наш сайт на регексах (т.п. регуляной грамматике) их влет разбирает: VD>
VD>@"Здраствуйте "" Досвидание"
VD>
Ну современный net-овский regex, с его жадным алгоритмом и соответвенно контекстно-зависимым — трудно назвать детерменированным конечным автоматом.
VD>Смотря что называть проходами.
Ну если все называть формальным термином, то о COCO/R говорят, что он создает частный случай автомата магазинного типа.
Здравствуйте, vdimas, Вы писали:
VD>>>Если только для хренового. Для лексеров C# и Nemerle это не так. Они прекрасно спрвляются с этой ситуацией. Попробуй ради хохмы в C# написать 2.ToString().
K>>Гм... Неужели такое может распознать ДКА?
V>Парсеры обычно как магазинные автоматы делают или LL(k) с примочками. Пусть токен "2." обозначает некий промежуточный нетерминал. Достаточно k=1 чтобы распознать выражение.
Обычно никто не разбирает код на лексемы с помощью магазинного автомата. Это слишком долго. Вот уже поток лексем анализируется парсером на основе магазинного автомата. Кстати, магазинный автомат распознаёт LR(k) грамматики, множество которых шире, нежели LL(k). LL(1) распознаются и рекурсивным спуском. А вот как для LL(k), так и для LR(k) при k > 1 приходится дополнительно извращаться, что дурно влияет на быстродействие.
Здравствуйте, konsoletyper, Вы писали:
K>Худший случай с 2 ^ n состояниями весьма непросто получить. Это надо специальный пример писать. ДЛя обычных языков как правило ДКА не сильно разбухает по сравнению с НКА.
Болие того ДКА не редко оказывается даже меньше...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, GlebZ, Вы писали:
VD>>А какие тут проблемы? Вон наш сайт на регексах (т.п. регуляной грамматике) их влет разбирает: VD>>
VD>>@"Здраствуйте "" Досвидание"
VD>>
GZ>Ну современный net-овский regex, с его жадным алгоритмом и соответвенно контекстно-зависимым — трудно назвать детерменированным конечным автоматом.
Теоритически любой конечный автома описывает исключительно регулярную граматику. Более того любой НКА можно переписать в ДКА. Вопрос только в том, что на прктике иногд ДКА получается очень большим. Но на то есть методы оптимизации.
Строки в Шарпе — это чистая регулярная грамматика. Вот если бы они допускали вложенные строки, то возникла бы проблема.
VD>>Смотря что называть проходами. GZ>Ну если все называть формальным термином, то о COCO/R говорят, что он создает частный случай автомата магазинного типа.
Коака — это лексер на базе ДКА с нельшим хаком + LL(1)-парсер оптимизированный с помощью таблицы предсказаний.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
K>Во-первых, никто ещё не тратил времени, только собираемся. Во-вторых, нужно тщательно перелопатить объектную модель отчётов. В-третьих, нужно сделать поддержку клиентских скриптов. В-четвёртых, ожидается общая поддержка скриптов, а там уже будут реализации. Просто реализацией по-умолчанию решили выбрать реализацию Питона.
Просто я как бы знаю много народа, которые могли бы писать на JScript, но знаю всего одного человека, который шарит в Питоне. У вас другая выборка?
Здравствуйте, konsoletyper, Вы писали:
K>Худший случай с 2 ^ n состояниями весьма непросто получить. Это надо специальный пример писать. ДЛя обычных языков как правило ДКА не сильно разбухает по сравнению с НКА.
Уже на C# получить огромнейший автомат раз плюнуть. Но есть пути оптимизации. Например, вместо того чтобы распознавать ключевые слова они проверяются по хэш-таблице.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, konsoletyper, Вы писали:
K>Обычно никто не разбирает код на лексемы с помощью магазинного автомата. Это слишком долго.
Это не то чтобы долго. Это бессмысленно. Для регулярных грамматик более чем подходят ДКА. Да и руками такие вещи пишутся на раз.
K> Вот уже поток лексем анализируется парсером на основе магазинного автомата.
Вообще-то наличие магазина (стэка или еще чего) это всего лишь принцип распознователя. Магазин просто увеличивает возмоности анализа, но качетсво анализа зависит от применяемого алгоритма. Например, есть GLR-парсеры распознающие очень большой класс граматик. А есть LALR-парсеры (Yacc-и) которые вообще без костылей почти ничего распознать не могут.
K> Кстати, магазинный автомат распознаёт LR(k) грамматики, множество которых шире, нежели LL(k).
Это совсем не так. У каждого есть свио проблемы. И каждый без костылей мало что можен. Но в общем случае LL(k), точнее даже LL(1) с заглядыванием вперд с целью отсечения неверных веток предпочтительнее. LL(1) дает лучший котроль ошибок, лучше отлаживается, проще в реализации. LR(k)-прасеров вообще встретить не просто. Реально применяются LALR-парсеры которые очень ограничены.
K> LL(1) распознаются и рекурсивным спуском. А вот как для LL(k), так и для LR(k) при k > 1 приходится дополнительно извращаться, что дурно влияет на быстродействие.
LR(k) распознается классическим ДКА с тем самым магазином. Вот только посторить именно LR(k) при больших k не просто. Одако есть алгоритм GLR который если мне не изменяет память при k, то ли равном 1, то ли небльшом дает очень хороший результат. И тем не мнее большинство парсеров реальных языков — это LL(1)-парсеры. Причем большая часть просто рукописные.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ie, Вы писали:
ie>Задумался тут.... А зачем они нужны?
А чем не аргумент "интеграция всего и вся рулит"? Когда проходится заниматься внедрением черт знает чего черт знает куда, это очень даже самоценный аргумент, вне зависимости от того, нужны ли вообще такие языки, и другой философии.
K>>Во-первых, никто ещё не тратил времени, только собираемся. Во-вторых, нужно тщательно перелопатить объектную модель отчётов. В-третьих, нужно сделать поддержку клиентских скриптов. В-четвёртых, ожидается общая поддержка скриптов, а там уже будут реализации. Просто реализацией по-умолчанию решили выбрать реализацию Питона.
V>Просто я как бы знаю много народа, которые могли бы писать на JScript, но знаю всего одного человека, который шарит в Питоне. У вас другая выборка?
Тут главный вопрос — как они программируют на JScript. 99% nt[? кого я знаю используют его в сугубо процедурном стиле
Здравствуйте, vdimas, Вы писали:
V>Не, нужно что-то типа среды смолтолка, чтобы запускать отдельные методы и ф-ии прямо из студии. Кстати, это все уже прекрасно работает в студии для VB.Net. Единственное неудобство — надо компилировать код после изменения. Зато потом играйся не хочу.
Далеко не все задачи хоть как то выиграют от возможности поиграться в студии.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, konsoletyper, Вы писали:
K>>Во-первых, никто ещё не тратил времени, только собираемся. Во-вторых, нужно тщательно перелопатить объектную модель отчётов. В-третьих, нужно сделать поддержку клиентских скриптов. В-четвёртых, ожидается общая поддержка скриптов, а там уже будут реализации. Просто реализацией по-умолчанию решили выбрать реализацию Питона.
V>Просто я как бы знаю много народа, которые могли бы писать на JScript, но знаю всего одного человека, который шарит в Питоне. У вас другая выборка?
Программировать на Питоне будет чел, занимающийся Репортером. Он действительно напишет ряд полезных функций для управления отчётами. Тем, кто имеет дело с бизнес-логикой, всё равно, как писать print a + b.
Здравствуйте, VladD2, Вы писали:
VD>Это не то чтобы долго. Это бессмысленно. Для регулярных грамматик более чем подходят ДКА. Да и руками такие вещи пишутся на раз.
Руками они пишутся день-два. Файл с описанием регулярной грамматики пишется за час-полтора (учитывая исправление граблей). Спрашивается, зачем тратить лишнее время?
VD>LR(k) распознается классическим ДКА с тем самым магазином. Вот только посторить именно LR(k) при больших k не просто. Одако есть алгоритм GLR который если мне не изменяет память при k, то ли равном 1, то ли небльшом дает очень хороший результат. И тем не мнее большинство парсеров реальных языков — это LL(1)-парсеры. Причем большая часть просто рукописные.
А какие есть тулзы для генерации кода парсеров? А то я что-то кроме как о вездесущем yacc ничего не слышал. Вроде есть что-то yacc-подобное в VS SDK. Но мне сам подход yacc не нравится. Очень уж коряво выглядит БНФ + код, всё это тяжеловато сопровождать. Почему бы не сделать генератор именно магазинного КА, а мы просто пишем парсер, который есть удобная обёртка над этим КА? Уж всё проще написать один небольшой декларативный файлик, по которому выйдет готовый КА, чем весь рекурсивный спуск ручками прописывать.
)
