Обсуждение:Сравнение генераторов парсеров

"Сбивает с толку"

Я отметил статью как запутанную, потому что я создал генератор парсера и хотел бы добавить его в список, но некоторые столбцы настолько непонятны, что я не уверен, что в них писать!

  • Я подозреваю, что «Грамматика, код» отвечает на вопрос «Действия, связанные с грамматикой, смешаны или отделены от грамматики?», верно?
  • Я полагаю, что столбец "Lexer" должен указывать, генерирует ли генератор парсеров лексеры и парсеры или только парсеры, но, возможно, было бы разумнее иметь два столбца "да/нет", "генерирует парсеры?" и "генерирует лексеры?". На самом деле есть три значения: "none", "generated" и "external", и я понятия не имею, в чем разница между "generated" и "external".
  • Я полагаю, что "IDE" означает либо "генератор парсера имеет собственную выделенную IDE", либо "генератор парсера интегрируется с одной или несколькими IDE". Конечно, это не должно быть столбцом "да/нет": в нем должно быть указано, имеет ли инструмент выделенную IDE, и если он интегрируется с IDE, то должно быть указано, с какой именно IDE.
  • "Входная грамматическая нотация" кажется странной, поскольку ANTLR помечена как "EBNF", но синтаксис ANTLR определенно отличается от EBNF, описанного в Википедии. Поскольку ANTLR так популярен, я склонен сказать, что мы просто называем эту нотацию "ANTLR".
  • «Алгоритм синтаксического анализа», похоже, объединяет две разные проблемы: тип входной грамматики (например, LALR(1), LL(k), PEG) и метод синтаксического анализа (например, таблично-управляемый, стековый рекурсивный спуск, packrat). В разделе «Детерминированные контекстно-свободные языки» «алгоритм синтаксического анализа», похоже, указывает тип входной грамматики, но в разделе «Анализ грамматик выражений» тип грамматики, по-видимому, «PEG», поэтому этот столбец вместо этого указывает метод синтаксического анализа. Возможно, разумно иметь оба в одном столбце, но давайте проясним, что тип грамматики и алгоритм синтаксического анализа — это две разные вещи.

Я прошу того, кто хорошо понимает эти таблицы, прояснить их, используя лучшие названия столбцов (например, интеграция IDE вместо просто «IDE») и добавив пояснительные абзацы или маркеры выше или ниже таблицы. Я бы также предложил объединить «Детерминированные контекстно-свободные языки» и «Грамматики выражений анализа», поскольку обе используются для анализа компьютерных языков. Я предполагаю, что «Общие контекстно-свободные, конъюнктивные или булевы языки» больше подходят для обработки естественного языка, поэтому, вероятно, разумно иметь отдельную таблицу; в любом случае, неочевидно, в чем разница между разделами; необходимы описательный текст и ссылки на другие статьи Википедии. Наконец, я думаю, что либо (A) должен быть дополнительный столбец для специальных возможностей генератора парсера, например, предикатов ANTLR с гейтом или анализа дерева, которые выходят «за рамки» возможностей типов грамматики, таких как LL(k) в теоретической литературе, либо (B) столбец «тип грамматики» мог бы упоминать специальные возможности (например, LL(*) + синтаксические/семантические предикаты). 66.11.82.73 ( обсуждение ) 23:18, 19 марта 2014 (UTC) [ ответ ]

Perl Parse::RecDescent

Где Perl Parse::RecDescent будет в этих таблицах? Я бы добавил его, но я не уверен в своих компиляторах. Он задокументирован на http://search.cpan.org/~jtbraun/Parse-RecDescent-1.967009/lib/Parse/RecDescent.pm

JidGom ( обсуждение ) 17:32, 4 декабря 2013 (UTC) [ ответить ]

Что такое ЛР(*)?

Может ли какой-либо эксперт в этой области подтвердить, что "LR(*)" является допустимым термином? Он упоминается как алгоритм синтаксического анализа для "Hime Paser Generator". Rasha ROR 1 ( обсуждение ) 13:20, 26 марта 2013 (UTC) [ ответить ]

Это похоже на LL(*) или ALL(*). ANTLR 4 выполняет анализ ALL(*). (*) означает, что анализатор выполняет просмотр вперед для принятия решения о разборе в неоднозначной ситуации.
LR(*) превосходит LR(1), потому что иногда по-человечески невозможно или нежелательно сделать грамматику LR(k) грамматикой LR(1). По крайней мере один генератор парсеров реализовал парсинг LR(*) (т. е. LRSTAR). Задача состоит в том, чтобы сделать LR(*) эффективным, чтобы он не влиял на производительность парсера. Пока k (число просмотров вперед) мало, парсинг LR(*) эффективен. — Предыдущий неподписанный комментарий добавлен Paulbmann ( talk • contribs ) 10:28, 23 мая 2019 (UTC)

Слияние

В связи с тем, что статья теперь содержит также список генераторов синтаксических анализаторов для обычных языков, предлагаю объединить статью со списком генераторов лексических анализаторов C Sharp . --Hyperyl ( обсуждение ) 22:54, 24 декабря 2008 (UTC) [ ответить ]

Я думаю, что другая статья гораздо более объективна, чем эта 189.89.156.99 ( обсуждение ) 21:08, 3 мая 2010 (UTC) [ ответ ]

 Сделано -- ebraminio talk 09:23, 18 декабря 2010 (UTC) [ ответить ]

Старое обсуждение

Эту страницу обсуждения необходимо очистить, упомянутые проблемы были решены!--Hyperyl 13:49, 11 ноября 2007 (UTC) [ ответить ]

Содержание статьи

Давайте решим, какая информация должна быть в статье — нужно ли описание различных столбцов и следует ли объединить две диаграммы. — DevinCook 13:43, 11 ноября 2007 (UTC) [ ответить ]

Да, пожалуйста, интегрируйте улучшенную версию старых описаний. Но сохраните текущую таблицу, ее редактирование потребовало много работы!--Hyperyl 13:49, 11 ноября 2007 (UTC) [ ответить ]
Я уверен, что на его редактирование ушла уйма времени! Я действительно считаю, что в колонках лицензий нужно указать Open Source/Freeware/и т. д... Только несколько программистов знают подробности каждой лицензии при беглом просмотре. Кроме того, термин «свободное ПО» — несмотря на то, что он возник в пропаганде бесхозного кода — больше не является хорошим термином. В наши дни он просто относится к «open source + public domain». Я признаю, что это нехорошо для движения, но такова реальность искусства. -- DevinCook 13:55, 11 ноября 2007 (UTC) [ ответить ]
Лицензии свободного ПО используют авторские права для защиты программного обеспечения, поэтому они не являются общественным достоянием. Требования к открытому исходному коду и свободному программному обеспечению одинаковы. Код не является бесхозным. Открытый исходный код — это просто маркетинговый термин. Пожалуйста, информируйте себя! Взгляните на страницы философии GNU!--Hyperyl 14:02, 11 ноября 2007 (UTC) [ ответить ]
Я хорошо знаком с терминологией. Свободное ПО в наши дни — это скорее философия, чем фактический термин лицензирования. Сообщество открытого ПО беспокоится о реализации исходного ПО, в то время как сообщество свободного ПО больше озабочено этическими вопросами. Открытый ПО оказался чрезвычайно успешным — в частности, Linux. Если использовать старую цитату Gnu: «Для движения открытого ПО вопрос о том, должно ли ПО быть открытым, является практическим, а не этическим вопросом. Как сказал один человек, «Открытый ПО — это методология разработки; свободное ПО — это социальное движение». Для движения открытого ПО несвободное ПО — это неоптимальное решение. Для движения свободного ПО несвободное ПО — это социальная проблема, а свободное ПО — это решение». Главный вопрос — сторонник Столлмана или сторонник Торвальдса. По большей части Торвальдс одержал верх, и «свободное ПО» в основном рассматривается как абсолютная форма «открытого ПО». — DevinCook 14:31, 11 ноября 2007 (UTC) [ ответить ]
Ну, я сторонник Столлмана. Между нами большая разница: вы пишете проприетарное ПО, а я его отвергаю. Так что между нами не будет консенсуса, потому что вы предпочитаете ограничения и пытаетесь подчинить пользователей, а я предпочитаю свободу и пытаюсь защитить пользователей.
Но взгляните на:
  • Категории свободного и несвободного программного обеспечения
  • Почему «открытый исходный код» не соответствует сути свободного программного обеспечения
--Hyperyl 15:32, 11 ноября 2007 (UTC) [ ответить ]

Бесплатное ПО против свободного ПО

Я предлагаю сохранить термин «бесплатное ПО» для описания программного обеспечения, доступного бесплатно. «Бесплатное ПО» по большей части является синонимом «open source» — что является логическим подмножеством бесплатного ПО.

Не все перечисленное программное обеспечение имеет открытый исходный код. -- DevinCook 23:59, 11 июля 2007 (UTC) [ ответить ]

Таким образом, это проприетарное ПО и должно быть включено в соответствующий раздел. Open Source — это маркетинговый термин с другим намерением, чем Free Software . Open Source фокусируется на технических аспектах, а Free Software — на философских проблемах и, таким образом, представляет философские ценности. Я думаю, что эти ценности гораздо важнее технических аспектов.
Кроме того, Freeware — это бесплатное проприетарное программное обеспечение. Таким образом, это не Free Software (программное обеспечение с открытым исходным кодом). Таким образом, программы Free Software не могут быть Freeware, потому что они уважают нашу свободу, а не ограничивают нас.
Если программа является частной собственностью и генерирует исходный код, лицензированный по лицензии свободного программного обеспечения, ее следует указать в разделе «Частное программное обеспечение», поскольку она по-прежнему ограничивает нас и не уважает нашу свободу.
Коммерческое означает взимание платы за программу или услугу, связанную с программой. Проприетарное и свободное ПО могут быть коммерческими, поэтому заголовок не имеет смысла.
Я отменил ваши правки по причинам, указанным выше. Пожалуйста, осведомитесь о том, о чем вы пишете. —Предыдущий неподписанный комментарий добавлен Hyperyl ( talk • contribs ) 21:32, 28 октября 2007 (UTC)[ отвечать ]
хм - такого рода замечания уместны на slashdot, а не в нейтральном, информативном контексте. Tedickey 21:52, 28 октября 2007 (UTC) [ ответить ]
Лучше всего обойтись без ярлыков и просто указать, какая лицензия применяется. Это нейтрально и только оскорбит тех, кто хочет заявить, что другие люди принадлежат к их группе Tedickey 21:58, 28 октября 2007 (UTC) [ ответить ]
Да, это хорошее решение!--Hyperyl 22:11, 28 октября 2007 (UTC) [ ответить ]
Генераторы парсеров изначально были перечислены в одной таблице. Я также разбил ее, чтобы позволить разработчикам увидеть, какие из них были коммерческими, а какие были доступны бесплатно. В том виде, в котором они сейчас находятся, это не так уж полезно для пользователей. GOLD не является коммерческим. Фактически, большинство элементов, перечисленных как «бесплатное ПО», не являются тем, что подразумевается под «бесплатным ПО». Одним из возможных решений является повторное объединение двух таблиц в одну. -- DevinCook 07:46, 29 октября 2007 (UTC) [ ответить ]
Я внес некоторые изменения, которые должны обеспечить хороший компромисс. -- DevinCook 07:46, 29 октября 2007 (UTC) [ ответить ]
Ваша аргументация не имеет смысла: Свободное ПО — это ПО, которое уважает свободу пользователя, все перечисленные программы уважают и, следовательно, являются Свободным ПО. Если вы хотите отфильтровать коммерческое ПО (ПО, которое не является бесплатным), вы можете просто отсортировать по лицензии или добавить поле цены. Разделение разделов, которое вы сделали, вообще не имеет смысла, вы поместили Проприетарное и Свободное ПО в один раздел. Это неэтично. Пожалуйста, объедините список, поскольку это было демократически (на основе консенсуса) решено. Я думаю, что это хороший компромисс (как и почти во всех других списках ПО). Все будут довольны. Возможно, вы могли бы поместить Проприетарные программы в конец списка, чтобы они были четко отделены от Свободного ПО. Но это, конечно, необязательно. Я бы также был рад списку, отсортированному в алфавитном порядке.--Hyperyl 18:57, 29 октября 2007 (UTC) [ ответить ]
Бесплатное программное обеспечение — это логическое подмножество программного обеспечения с открытым исходным кодом. Раздел предназначен для перечисления названий программного обеспечения, которое пользователь может использовать бесплатно. К сожалению, терминология, которую мы все используем, немного кошмарна — и причина этого спора. «Бесплатное программное обеспечение» бесплатно, но не все названия свободного программного обеспечения являются «бесплатным программным обеспечением». Главное различие между «бесплатным программным обеспечением» и «бесплатным программным обеспечением» заключается в том, является ли исходный код открытым. По определению «бесплатное программное обеспечение» является проприетарным. Однако разделение было основано на коммерческом и бесплатном, а не на доступности исходного кода. — DevinCook 19:25, 29 октября 2007 (UTC) [ ответить ]
Девин, это моя последняя попытка объяснить тебе, что такое свободное ПО. По определению свободное ПО и ПО с открытым исходным кодом — это одно и то же. Их определения описывают четыре основные свободы. Открытый исходный код — это маркетинговый термин, который был придуман, потому что бизнесмены путали свободное ПО с открытым исходным кодом. Таким образом, свободное ПО не является подмножеством открытого исходного кода — оно равно ему. Не следует делить ПО на категории стоимости. Это бесполезно. Бесплатная копия патентованной программы все равно неэтична и бесполезна (потому что вы не свободны и не можете должным образом использовать (с точки зрения использования, обучения, сотрудничества и разработки) программное обеспечение). Бесплатное программное обеспечение является бесплатным. Патентованное программное обеспечение и свободное программное обеспечение не обязаны быть бесплатными. Свобода — это разница, а исходный код и приписываемые права являются требованиями для этой свободы. Вы не должны определять бесплатное как бесплатное. Оно бесплатно в смысле свободы, а не в смысле цены. Лицензии свободного программного обеспечения никогда не предъявляют никаких требований относительно цены. Их цель — свобода, которая гораздо ценнее денег. Если вы все еще думаете, что деньги важнее свободы, я не могу вам помочь, потому что вам нравится быть рабом, вам нравится быть подчиненным. Поэтому, пожалуйста, исправьте свои ошибки!--Hyperyl 23:02, 29 октября 2007 (UTC) [ ответить ]
Кстати, почему вы ведете себя так, будто вы авторитет в этом вопросе? Tedickey 23:59, 29 октября 2007 (UTC) [ ответить ]

Определения

В: Как здесь определяется Грамматика/код : смешанный или разделенный . Отделенный от Кода (без Кода внутри) или как независимый Файл? 129.69.189.32 20:56, 12 октября 2006 (UTC) [ ответить ]

Объяснение

Эта таблица требует гораздо большего объяснения. Например, добавление вики-ссылок на LALR и т. д., что означает «разделенный» и «смешанный» (согласно вышеизложенному), и т. д., и т. д., и т. д. — Предыдущий неподписанный комментарий был добавлен 71.70.210.188 (обсуждение) 00:09, 11 декабря 2006 (UTC). [ ответить ]

Вводящее в заблуждение название статьи

Привет, предлагаю изменить название этой статьи на Список генераторов парсеров . Эта статья о генераторах парсеров, а не о парсерах, не так ли? eboy 15:55, 31 августа 2007 (UTC) [ ответить ]

Отличное замечание. Первоначально статья называлась «Список компиляторов-компиляторов», однако многие пункты в списке не являются компиляторами-компиляторами, включая мой проект. Я согласен, что изменение заголовка на «Список генераторов парсеров» или, возможно, «Список программного обеспечения для разработки парсеров» было бы полезным. Что вы думаете по этому поводу? -- DevinCook 20:59, 1 сентября 2007 (UTC) [ ответить ]
Согласен, мне больше всего нравится «Список генераторов парсеров». // Sping 20:24, 14 сентября 2007 (UTC) [ ответить ]

В списке генераторы, имеющие Wiki-страницу (ANTLR), имеющие внешнюю ссылку (ACCENT) и не имеющие Wiki и внешнюю ссылку (Grammatica). Мое предложение — новая колонка с внешней ссылкой; это дает преимущества:

прямой переход на домашнюю страницу генератора, независимо от того, есть ли у генератора страница Wiki или нет
мгновенно можно увидеть (по цвету), есть ли у генератора страница Wiki или нет

-- Borneq 08:11, 18 октября 2007 (UTC) [ ответить ]

Предлагаю удалить ссылки на сайты генераторов парсеров, так как это выглядит некрасиво и дублирует усилия страниц статей (если они есть), на которых они уже указаны.

Поэтому я предлагаю связать названия генераторов парсеров, у которых нет статьи в Википедии, с их веб-сайтами. —Предыдущий неподписанный комментарий, добавленный Hyperyl ( обсуждение • вклад ) 23:01, 24 декабря 2008 (UTC) [ ответить ]

Звучит как хорошая идея. Большая часть данных на этой странице взята из непримечательных программ, в основном добавленных их разработчиками Tedickey ( обсуждение ) 17:59, 15 мая 2010 (UTC) [ ответить ]

непримечательная программа Waxeye

Недавние правки добавили "Waxeye", который (см. google "waxeye parser"), по-видимому, не представляет интереса. Tedickey ( обсуждение ) 10:27, 30 декабря 2008 (UTC) [ ответить ]

Для контекста, большинство результатов поиска в Google по запросу "waxeye" относятся к птице. Программа имеет несколько сотен результатов, что на несколько порядков меньше, чем можно было бы ожидать для темы Википедии. Tedickey ( talk ) 10:28, 30 декабря 2008 (UTC) [ ответить ]

Действительно ли Yacc++ LR(k)/LALR(k)?

Насколько вы уверены, что Yacc++ — это LR(k)/LALR(k). k, похоже, подразумевает, что он имеет неограниченный просмотр вперед, но насколько я могу судить по странице обзора веб-сайта, Yacc++ — это LR(1)/LALR(1). Errantkid ( обсуждение ) 21:47, 28 января 2009 (UTC) [ ответ ]

Я его меняю. Пожалуйста, если кто-то не согласен, дайте нам знать Errantkid ( обсуждение ) 21:09, 11 июня 2009 (UTC) [ ответить ]

На самом деле это LR(k), и есть два способа достижения этой функциональности.

Во-первых, при выполнении расчетов опережающего просмотра синтаксический анализатор может фактически обратиться к нетерминалу, а не просто к терминальному символу, если нетерминал представляет собой что-то неограниченной длины, опережающий просмотр, который он разрешает, имеет неограниченную длину — это по сути форма возврата (и зависит от того, что наша реализация «стека» парсера на самом деле больше похожа на дек или, может быть, на пару дек). Этот метод является несколько экспериментальным и требует параметра командной строки для включения, и мы никогда не находили его полезным на практике, например, мы никогда не находили неигрушечную грамматику, которая бы компилировалась с включенным методом, но не компилировалась бы обычными методами — он не разрешал волшебным образом все конфликты в нашей грамматике C++. Я всегда хотел написать техническую статью с описанием этой техники, но моя основная работа никогда не оставляла на это времени — никто не может зарабатывать на жизнь написанием генераторов парсеров.

Во-вторых, пользователь также может применять предикаты в любом месте правила, и снова эти предикаты являются регулярными выражениями нетерминалов, которые по сути позволяют пользователю задать язык LR(k) в качестве предпросмотра в этой конкретной точке грамматики — по сути, это функция грамматики выражений синтаксического анализа (PEG), и она работает аналогично механизму в ANTLR, откуда мы позаимствовали эту идею, но сделали это с использованием методов LR, а не LL, используя вариацию идеи «туннельных грамматик», которую Йозеф Грёльш изобрел для Cocktail. Опять же, по сути, это метод обратного отслеживания, но в этом случае пользователь точно указывает, где он должен произойти в процессе синтаксического анализа, поэтому вы можете ограничить его влияние, поскольку все методы обратного отслеживания часто сводят на нет линейное обещание синтаксического анализа LR (и LL). Тем не менее, это практично, и кто-то, Борис Бурштиен (исп.?) или, возможно, Куинн Тайлер-Джексон, однажды показал, как можно использовать эту технику для имитации машины Тьюринга, так что она также является совершенно общей.

93.40.177.50 (обсуждение) 10:12, 1 января 2017 (UTC) Кристофер Ф. Кларк [ ответить ]

LL(1) = Рекурсивный спуск

Я думаю, было бы лучше заменить все "LL(1)" и "Recursive Descent" на LL(1) . -- Chricho ( обсуждение ) 20:22, 9 марта 2010 (UTC) [ ответить ]

GLR для CFG

Следует ли заменить CFG на «детерминированный CFG»? -- Chricho ( обсуждение ) 18:47, 3 декабря 2010 (UTC) Однако есть генератор парсеров Earley, который, очевидно, может обрабатывать недетерминированные CFG, поэтому я думаю, что его следует объединить с генераторами GLR. Я думаю, мы можем игнорировать тот факт, что парсеры с возвратом также могут обрабатывать недетерминированные/неоднозначные грамматики. Есть ли какая-то особая причина для разделения генераторов парсеров Packrat? Грамматики, с которыми они могут работать, являются надмножеством LL(1), но не надмножеством LR(1) или LL(k), поэтому я не думаю, что они играют в другой лиге. -- Chricho ( обс. ) 18:54, 3 декабря 2010 (UTC) Изменено… -- Chricho ( обс. ) 19:21, 3 декабря 2010 (UTC) [ ответить ]

Какие у вас есть доказательства того, что генераторы Packrat-парсеров являются подмножеством LR(1)? Было показано, что парсеры с обратным отслеживанием (использующие предикаты) эмулируют машины Тьюринга, поэтому я бы предположил, что PEG могут делать то же самое.

93.40.177.50 (обсуждение) 10:33, 1 января 2017 (UTC) Кристофер Ф. Кларк [ ответить ]

Очистка Redlink удалила следующую информацию, содержащуюся в имени ссылки или несуществующем заголовке статьи. Она может быть реинтегрирована, например, тот факт, что Narwhale — это генератор парсеров, Packrat — это библиотека, и что означает GDK.

Сокращения

  • Комплект для развертывания грамматики|GDK
  • Генератор парсера LALR|LPG
  • Генератор лексического анализатора и парсера|Lapg

Библиотеки

  • Библиотека шаблонов грамматики выражений анализа|PEGTL
  • Библиотека парсера Parsnip|Parsnip
  • Фрисби (библиотека)|Фрисби
  • Packrat (библиотека)|Packrat

Лексеры

  • Турбо Паскаль Лекс/Yacc|TP Yacc
  • Алекс (генератор лексера)|Алекс
  • Dolphin (генератор лексеров)|Dolphin
  • DFA (генератор лексеров)|LRSTAR

Парсеры

  • Msta-парсер|Msta
  • Laja (парсер и генератор кода)|Laja
  • Laja (парсер и генератор кода)|Laja
  • APG (генератор парсеров)|APG
  • Зубры (генератор синтаксического анализатора)|Зуры
  • Austenx (генератор парсеров)|AustenX
  • AustenX (генератор парсеров)|AustenX
  • Beaver (генератор парсеров)|Beaver
  • CSP (генератор парсеров)|CSP
  • CUP (генератор парсеров)|CUP
  • Dragon (генератор парсеров)|Dragon
  • Dypgen (генератор парсеров)|Dypgen
  • eli (генератор парсеров)|eli
  • Elkhound (генератор парсеров)|Elkhound
  • jay (генератор парсеров)|jay
  • Lime (генератор парсеров)|Lime
  • LISA (генератор парсеров)|LISA
  • Менгир (генератор парсера)|Менгир
  • Monkey (генератор парсеров)|Monkey
  • Narwhal (генератор парсеров)|Narwhal
  • peg (генератор парсеров)|peg
  • SLK (генератор парсеров)|SLK
  • SPARK (генератор парсеров)|SPARK
  • Styx (генератор парсеров)|Styx
  • Tap (генератор парсеров)|Tap
  • Том (генератор парсеров)|Том
  • Waxeye (генератор парсеров)|Waxeye
  • Whale (генератор парсеров)|Whale
  • Wisent (генератор парсера)|Wisent
  • Yard (генератор парсеров)|Yard
  • Счастливый (Парсер)|Счастливый
  • Парсек (парсер)|Парсек
  • Sprache (парсер)|Sprache

Язык программирования и программное обеспечение

  • Катадин (язык программирования)|Катадин
  • Essence (программное обеспечение)|Essence
  • Treetop (программное обеспечение)|Treetop

— Cp i r al Cpiral 16:51, 8 сентября 2013 (UTC) [ ответить ]

Это проблематично: большая часть контента по этой теме содержит список непримечательных программ, которые малоинтересны никому, кроме тех, кто добавил внешние ссылки (вероятно, их разработчиков). TEDickey ( обсуждение ) 17:24, 8 сентября 2013 (UTC) [ ответить ]

В вашем списке есть несколько генераторов парсеров, которые я бы посчитал важными.

LALR (и его потомок LRSTAR) Пола Манна были одними из самых популярных генераторов парсеров на ПК в 1980-х и 90-х годах.

ELI была (есть?) очень обширной системой компилятор-компилятор, разработанной консорциумом университетов, включая Университет Колорадо. Это одна из немногих известных мне систем, которая пытается иметь нотации, решающие другие части проблемы построения компилятора за пределами лексического анализа и парсинга.

Если я правильно помню, у Элкхаунда, Менгира, Хэппи и Парсека были (есть?) последователи и помимо их первоначального автора.

93.40.177.50 (обсуждение) 11:15, 1 января 2017 (UTC) Кристофер Ф. Кларк [ ответить ]

PEG.js — это не Packrat

Packrat имеет время выполнения O(N), но с помощью PEG.js вы можете легко проверить время выполнения O(N^2) с помощью грамматики:

С = ( Х / . )*X = "а" [аб]* "б"

Запуск этого с включенным кэшем с длинной строкой символов "a" даст время выполнения O(N^2). Существует ошибочное мнение, что любой рекурсивный спусковой анализатор с мемоизацией является анализатором packrat. Это не так: анализатор packrat достигает времени выполнения O(N) за счет мемоизации результата каждого подвыражения в каждой позиции символа, включая рекурсивно развернутые операторы повторения. PEG.js просто кэширует результат всего правила X.

Вероятно, многие из парсеров, помеченных как "packrat" в этой таблице, на самом деле не являются packrat, но я просто изменю PEG.js на данный момент. Я назову его парсером рекурсивного спуска, что является разумным приближением, этот термин также использует автор [1] -- Тим Старлинг ( обсуждение ) 00:53, 4 июня 2015 (UTC) [ ответить ]

OMeta не Packrat

В том же духе, что и Тим Старлинг, я подтвердил, что OMeta также не полностью packrat. CF 2.2.3 "Заметка о мемоизации" на странице 41 http://www.vpri.org/pdf/tr2008003_experimenting.pdf . В настоящее время в таблице он обозначен как "Packrat (модифицированный)". Я предлагаю стандартизировать скобки, например "(выборочный)", которые также используются для описания нескольких других генераторов парсеров, чтобы описать эти общие варианты анализа packrat, а не возвращаться к общему "рекурсивному спуску". C. Scott Ananian ( обсуждение ) 17:28, 18 июня 2015 (UTC) [ ответ ]

у них у всех отсутствует GUI (графический интерфейс пользователя)?

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

Итак, главный вопрос: неужели у ВСЕХ из них отсутствует (хороший, интуитивно понятный, полезный) графический интерфейс???

78.227.78.135 ( обсуждение ) 21:54, 9 ноября 2015 (UTC) [ ответить ]


например: https://github.com/akshayhebbarys/lalr-parser графический интерфейс довольно плохой... у них всего 4 примера, ни один из которых не является просто анализатором арифметических выражений... мы в 2015 году, а инструменты практически не развивались с 1990 года (bison) !!!! 78.227.78.135 ( обсуждение ) 23:54, 9 ноября 2015 (UTC) [ ответить ]

Большинству генераторов парсеров нравится "хороший" (или любой) GUI. Однако из обычно надежных источников я знаю, что тот, что с Visual Parse++, был хорош. К сожалению, этот генератор парсеров (и его GUI) больше недоступен. Я связывался с автором, но так и не смог возродить продукт. Стоимость создания (и поддержки) генератора парсеров, помимо создания генератора "студенческого" качества, просто коммерчески непомерна, а рынок исчезающе мал.

93.40.177.50 (обсуждение) 10:28, 1 января 2017 (UTC) Кристофер Ф. Кларк [ ответить ]

Лицензия генератора парсера SLK не похожа на лицензию MIT

Лицензия MIT явно предоставляет широкие права на использование и распространение программного обеспечения:

 Настоящим предоставляется разрешение любому лицу, получившему копию этого программного обеспечения и связанных с ним файлов документации («Программное обеспечение»), безвозмездно использовать Программное обеспечение без ограничений, включая, помимо прочего, права *использовать, копировать, изменять, объединять, публиковать, распространять, сублицензировать и/или продавать* копии Программного обеспечения, а также разрешать лицам, которым предоставляется Программное обеспечение, делать это при соблюдении следующих условий:

Именно такое предоставление широких прав для большинства людей означает, что лицензия «подобна MIT».

Лицензия SLK этого не делает:

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

Я не уверен, что на самом деле имели в виду авторы лицензии SLK, но на первый взгляд эта лицензия кажется гораздо более ограничительной, чем лицензия MIT. Мое (неюридическое) толкование этой лицензии заключается в том, что она, вероятно, позволяет вам загружать программное обеспечение и использовать его как есть, но не изменять его или распространять. Таким образом, я считаю, что называть лицензию SLK «подобной MIT» вводит в заблуждение, и я удаляю это утверждение из таблицы.

Я отмечу, что сравнение с лицензией MIT, похоже, не исходит из проекта SLK. Я не могу найти никаких заявлений об их лицензии на их сайте, кроме текста самой лицензии. Я нашел по крайней мере еще одну страницу, называющую ее «подобной MIT», но они могли использовать Википедию в качестве источника. — Предыдущий неподписанный комментарий добавлен Nculwell (обсуждение • contribs ) 16:54, 27 марта 2019 (UTC) [ ответить ]

Обзор известности

Две таблицы в этой статье очень неразборчивы, в основном состоящие из непримечательных проектов , которые получили очень мало принятия, если вообще получили. Я начал обзор таблицы для «Детерминированных контекстно-свободных языков». Если кто-то хочет помочь, пожалуйста, продолжайте работать с этой таблицей, добавляя ссылки на надежные вторичные источники и удаляя строки, если их не удается найти. Записи не обязательно должны соответствовать общим правилам значимости и быть самостоятельными статьями, но они должны иметь по крайней мере один надежный вторичный источник, описывающий их (и не мимоходом ) . StereoFolic ( обсуждение ) 18:22, 16 сентября 2023 (UTC) [ ответ ]

Примечательна ли Carburetta?

Только что внес изменения, пытаясь исправить то, что было отменено, но текущее состояние все еще непоследовательно. Carburetta — это сканер C/C++ *и* генератор парсеров (то есть оба), занимает первое место по "генератору сканеров C", четвертое место по "генератору парсеров C" (выше bison и lemon, но ниже "PackCC") и похоже, но ниже, по C++ и так далее.

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

Может ли кто-нибудь объяснить, как измеряется "Notability" в строке таблицы в этом смысле? Субъективно это или объективно, и если да, то каковы критерии. И почему это применимо к одной таблице, но не к другой (где Carburetta все еще появляется? Он хорош как генератор сканера, но именно как генератор парсера он блистает.)

Кроме того, читая обсуждение, могу ли я предложить упростить статью до двух таблиц? «сканеры» и «парсеры» (или лексеры и парсеры?). За исключением нескольких исследовательских проектов, я думаю, что именно здесь большинство практиков проведут самую большую черту на песке? (Возможно, сканеры даже не относятся к списку парсеров.)

Я здесь новичок, учусь по ходу дела, так что не стесняйтесь указывать мне на вещи, даже на те, которые должны быть очевидны большинству. Bravingtheabyss (обсуждение) 21:24, 17 января 2024 (UTC) [ ответить ]

WP:NOTABILITY и WP:RS — хорошее место для начала чтения TEDickey ( обсуждение ) 00:00, 18 января 2024 (UTC) [ ответить ]
Привет, Bravingtheabyss, добро пожаловать в Википедию! Правила по значимости в записях в статьях-списках, подобных этой, немного двусмысленны. Общие правила значимости применяются к темам статей, а не к их содержанию, но их определенно стоит прочитать, чтобы понять общие подходы к значимости. Правила в WP:Stand-alone lists также актуальны здесь.
Я уже некоторое время провожу (медленный) обзор известности этой статьи (см. ветку выше), так как заметил, что приличное большинство записей явно не примечательны. Правило большого пальца, которое я использовал, таково: «Могу ли я найти какой-либо сторонний надежный источник , обсуждающий это программное обеспечение более чем мимолетно ?» Я не смог найти ничего подобного для Carburetta, поэтому я просто удалил его из другого списка. Я не думаю, что была какая-то особая причина, по которой он был включен в один список, но не в другой, различия часто довольно неясны, и это одна из многих проблем с этой статьей. В любом случае, рейтинги поиска определенно не являются полезным показателем известности, особенно с такими сервисами, как Google, которые настраивают результаты для каждого пользователя!
Пожалуйста, дайте нам знать, если это не ясно, я с радостью отвечу на любые другие вопросы! StereoFolic ( обсуждение ) 02:19, 18 января 2024 (UTC) [ ответить ]
@ StereoFolic , @ Tedickey спасибо, что нашли время ответить подробно. Позвольте мне просто сказать, что все, что вы говорите, имеет для меня смысл. Однако я беспокоюсь, что это может сместить списки в сторону работ из академической среды, а не "работ из промышленности", если можно так выразиться. Некоторые независимые упоминания могут включать его пакет netbsd [2]https://pkgsrc.se/wip/carburetta как надежный второй источник, и некоторые "упоминания мимоходом" здесь: [3]https://stackoverflow.com/questions/12768411/yyparse-not-declared-in-bison-flex-c-project-only-for-some-version-of-gcc-bi и здесь: [4]https://stackoverflow.com/questions/76133442/parsing-a-wrapped-csv-file-with-only-one-pass-over-line-string
Подводя итог, я думаю, что есть три вопроса: 1) станет ли Википедия лучше, если ее включить? 2) должна ли она иметь ссылку на свой веб-сайт? и 3) должна ли статья применять два разных стандарта в зависимости от обсуждаемого нами списка?
1) что лучше всего подходит для Википедии? Предположительно, цель списка — информировать исследователей и/или инженеров о предыдущих работах, а пользователей — о вариантах. Я считаю, что список будет лучше, если в него будут включены существенные варианты с открытым исходным кодом.
2) ссылка на то, где? с целью первого, возможно, если не как ссылка, таблица должна рассмотреть дополнительный столбец, указывающий читателям, куда идти. Лучшим ресурсом для этого, я считаю, является руководство; поскольку оно должно информировать, а не убеждать, относительно любых утверждений.
3) carburetta, из-за своей способности генерировать как сканер, так и парсер независимо и объединенно, упоминается на этой странице не в одном, а в *двух* списках. Страница должна быть последовательной.
Учитывая это и считая благополучие Википедии приоритетом, я считаю, что нам следует рассмотреть следующие вопросы:
A) Отменить возврат, руководствуясь изложенной выше логикой и наилучшими интересами, или, в противном случае,
B) Включить Carburetta в оба списка, но без явной ссылки или со ссылкой на ее руководство (например, в качестве заменителя бумажной ссылки) или, если это невозможно,
C) Удалить Carburetta из обоих списков (не имеет смысла рассматривать ее отдельно с точки зрения ее возможностей генерации сканеров, не рассматривая ее с точки зрения ее возможностей генерации парсеров), чтобы добиться согласованности применяемых стандартов.
В любом случае, как я надеюсь, вы согласитесь, текущее состояние статьи не является правильным. Конфликт моей предвзятости и желания быть хорошим гражданином означает, что я оставлю это вам решать. Мне было бы комфортно, хотя лично я был бы очень разочарован, с вариантом C). Bravingtheabyss (обсуждение) 08:19, 18 января 2024 (UTC) [ ответить ]
Требование наличия хотя бы одного стороннего надежного источника, обсуждающего программу, действительно может привести к некоторым предвзятым мнениям, однако альтернативой является включение подавляющего количества программ сомнительной ценности.
Вред Википедии от чрезмерного включения заключается в том, что статьи могут стать слишком длинными, сложными для навигации и невозможными для точного поддержания. Неразборчивая длина этой статьи является ключевой причиной, по которой в ней так много неточностей. Википедия не является архивом или заменой поисковой системы, поэтому нам не нужно включать все, что находится под солнцем. См. также WP:INDISCRIMINATE . Основные генераторы парсеров, которые активно используются в промышленности, имеют множество надежных источников, обсуждающих их. Надежные источники не обязательно должны быть академическими — они могут быть от любого признанного эксперта в предметной области . Первичные источники также можно включать для базовой фактической информации, но не для известности.
Посты Stackoverflow и списки дистрибутивов пакетов не считаются надежными источниками, поскольку и то, и другое очень легко создать любому человеку, и, очевидно, существует множество опубликованных пакетов, которые не являются примечательными. Только в NPM имеется более миллиона пакетов!
Что касается включения Carburetta, я уже полностью удалил его из статьи (ваш вариант C) на основании, описанном выше. StereoFolic ( обсуждение ) 17:26, 18 января 2024 (UTC) [ ответить ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_parser_generators&oldid=1206764828"