Предполагаю, вы имеете в виду IBM PL/I и COBOL. (Не так много других PL/вокруг, но я не думаю, что это действительно сильно меняет ответ).
Очевидное место для поиска зрелых грамматик ANTLR - ANTLR3 grammar library; нет грамматик PL/1 или COBOL. Antlr V4 (очень новая, радикальная, обратная несовместимая реинжиниринг ANTLR3) рассказывает о Java и C#; нет намека на PL/1 или COBOL; учитывая его новизну, не удивительно. Если вам действительно повезло, у кого-то может быть один, который они вам дадут и выступит.
Разработка таких грамматик трудно по нескольким причинам (на основе личного опыта строительства анализаторами производства качественных для этих двух конкретных пунктов, используя очень сильную систему парсер иначе, чем ANTLR [см мой био для получения более подробной информации]):
- Правила набора символов и раскладки столбцов (столбцы 1-5, 6 и 72-80 являются специальными) могут быть проблемой: языки, которые вы описываете, обычно записываются в EBCDIC исторически в формате столбца 80-ти столбцов без символов разрыва строки между линиями. Перевод в ASCII иногда вызывает неприятные глюки; конечный символ ASCII иногда встречается в середине литеральных строк COBOL в качестве двоичного значения, но поскольку он имеет точно такой же код в EBCDIC и ASCII, после перевода он будет (be и) казаться ASCII символ прерывания строки. Строки символов также могут быть длинными, но разделены на несколько строк; но столбцы 72-80 по определению следует игнорировать. Столбец 6 может содержать символ «D», который влияет на интерпретацию следующих строк источника как «отладка» или «нет». Это означает, что вам нужно правильно обработать 80 столбцов. Я не знаю, что ANTLR должен поддерживать обработку символов в столбцах. Вам также нужно будет беспокоиться о кодировании строковых литералов DBCS и их вариантах, если исходный код используется в неанглоязычных странах, таких как Япония.
- Эти языки большие и сложные; У IBM было 40 лет, чтобы украсить их рывком. Руководство IBM COBOL составляет около 600 страниц ... тогда вы обнаружите, что COBOL также включает в себя Report Writer, который является еще 600 страниц документа. Захват всех нюансов лексических токенов и правил грамматики потребует усилий, и вы должны сделать это из руководств IBM, которые не содержат красивого описания стиля BNF, что означает угадывание из текстового описания и некоторых примеров. Для COBOL ожидайте несколько тысяч правил грамматики; PL/1 менее сложна в абстрактной форме. Ожидайте определенное количество «лжи»; мы столкнулись с рядом мест, где в справочной документации четко говорится, что некоторые вещи не являются законными, и все же компиляторы IBM (на основе реального, работающего исходного кода) принимают их, и наоборот. Единственный способ их найти - это эмпирические эксперименты.
- Оба языка имеют конструкции, которые трудно разобрать, например, требуя произвольного искажения и/или локальной неоднозначности. ANTLR4 намного лучше, чем ANTLR3, из моего понимания по этим вопросам, но это не означает, что эти аспекты будут легкими. PL/1 особенно неприятен в этом отношении: у него нет ключевых слов, но сотни ключевых слов в контексте. Чтобы решить эту проблему, нужно заставить лексер и парсер сотрудничать, и даже тогда может быть много локально неоднозначных парсов. ANTLR3 не делает это хорошо; Предполагается, что ANTLR4 будет лучше, но я не знаю, как он справляется с этим, если он вообще это делает.
- Чтобы проверить правильность этих парсеров, вам необходимо запустить их на миллионы строк кода (что означает, что вы должны иметь доступ к таким образцам кода) и исправить любые обнаруженные ошибки. Это занимает много времени (в нашем случае, несколько лет более или менее непрерывной работы/улучшения, чтобы получить грамматики качества продукции, которые работают на больших кодовых основаниях). Вы можете быть чудом быстрее этого; удачи.
- Вам необходимо создать препроцессор для COBOL (КОПИРОВАНИЕ ... ЗАМЕНА), чьи данные плохо документированы и, в конечном счете, еще один для PL/1 (который, как я понимаю, полностью поддерживает Turing).
- После того, как вы создаете парсер, вам нужно захватить дерево синтаксиса; здесь ANTLR4 должен быть довольно хорош тем, что он будет захватывать один для грамматики, которую вы ему даете. Это может быть или не быть АСТ, которого вы хотите; с несколькими тысячами правил грамматики, я бы не ожидал. ANTLR3 требует, чтобы вы вручную добавляли указания о том, где и как формировать AST.
После того, как вы получите AST, вы захотите что-то с этим сделать. Это означает, что вам нужно будет создать по крайней мере таблицы символов (сопоставление от экземпляров идентификатора к их объявлениям и любой связанной информации о типе). ANTLR не предоставляет ничего особенного для поддержки этого AFAIK, за исключением поддержки при ходьбе AST. Это тоже трудно понять, у COBOL есть сумасшедшие правила о том, как ссылку на неквалифицированный идентификатор можно интерпретировать как конкретное поле данных, если нет других противоречивых интерпретаций. (Если вы хотите иметь хорошую семантическую информацию о программе, есть еще много возможностей для Life After Parsing, см. Мою биографию для более подробной информации, для каждого из этих семантических аспектов вы их разрабатываете, а затем для проверки возвращаетесь и запускаете их на больших кодовых основаниях еще раз.).
TL; DR
Строительные парсеры (ну, «передние концы») для этих языков не является много работы независимо от того, что синтаксического двигателя вы выбираете. Вероятно, объясняет, почему они еще не находятся в грамматическом зоопарке ANTLR.
Большое спасибо Ира, я ценю это –
Плохие новости лучше, чем нет новостей ... Спасибо – Malta