Pegjs: Импорт / включение других грамматик

Я согласен, что это важная функция, я хочу сделать это после версии 1.0.

(Кстати, мне не нравится Python-подобный синтаксис, который вы предлагаете - что-то похожее на require Node.js было бы лучше, потому что это было бы более знакомо программистам JavaScript. Но это второстепенная вещь, которую можно утюжить позже.)

Вы бы рассматривали его для включения до версии 1.0, если бы он был снабжен патчем?

Я согласен с вашим замечанием о синтаксисе Python.

+1 за эту функцию

@ceymard Да, я бы рассмотрел это.

+1 за функцию и +1 за включение стиля require

@dmajda @ceymard У вас уже есть мысли о том, как это реализовать? Мне это нужно для проекта на работе и я постараюсь реализовать. Вопрос в том, должно ли это быть просто добавлением к разделению грамматик на несколько файлов или чем-то вроде наследования, чтобы можно было, например, унаследовать все правила, а затем перезаписать определенные правила в новой грамматике.

@Dignifiedquire В настоящее время я думаю о синтаксисе и семантике, которые, вероятно, лучше всего можно объяснить на примере:

static-languages.pegjs

langauges  = "C" / "C++" / "Java" / "C#"

динамический-languages.pegjs

languages = "Ruby" / "Python" / "JavaScript"

all-languages.pegjs

static  = require("./static-languages")
dynamic = require("./dynamic-languages")

all = static.languages / dynamic.languages

Каждый файл .pegjs будет неявно определять модуль, который будет экспортировать все содержащиеся в нем правила. Конструкция <name> = require(<module>) импортирует такой модуль. Тогда его правила будут доступны внутри пространства имен.

Этот дизайн намеренно похож на Node.js. Использование пространств имен позволит избежать конфликтов. Я вижу два недостатка:

1. Конструкция <name> = require(<module>) слишком похожа на определения правил и поэтому может сбивать с толку (можно подумать, что импортируется только одно правило).
2. Синтаксис . конфликтует с текущим значением . , которое является «любым символом». Это можно решить с помощью уродливых приемов (например, . окруженного пробелом, означает «любой символ», а . окруженный идентификаторами, отделяет имя пространства имен от имени правила) или путем изменения синтаксиса (например, с использованием ключевого слова any для представления «любого символа»).

@dmajda Поскольку <identifier> = <expression> уже используется определениями правил, почему бы не сделать что-то вроде этого:

static := require("./static-languages")
dynamic := require("./dynamic-languages")

all = static::languages / dynamic::languages

:: нигде, насколько мне известно, в PEG.js не используется и позволяет легко различать пространства имен и другие вещи. Я не уверен насчет := он передает, но кажется очень чуждым Javascript ..

Также, если вы хотите использовать пространства имен, считаете ли вы, что должно быть только одно пространство имен для каждого файла или должен существовать способ создания нескольких пространств имен в одном файле, например:

static := {
  languages  = "C" / "C++" / "Java" / "C#"
}

dynamic := {
  languages = "Ruby" / "Python" / "JavaScript"
}

Я не большой поклонник :: и := , они выглядят чужими в мире javaScript / CoffeeScript.

Я также хотел бы, чтобы все было просто и неявно определять пространства имен, только запрашивая файлы. Не вижу большой необходимости в чем-то более сложном.

Как насчет того, чтобы просто:

<strong i="6">@require</strong> foo = "./foo"

bar = foo:languages

Двоеточие - это компромисс, но они используются для разделения пространств имен во многих местах: C ++, C #, XML и т. Д.

: всегда будет ассоциироваться с cons для многих, многих функциональных программистов. Я предлагаю держаться подальше от этого оператора. Мне нравится :: . Разве это не используется для пространств имен C ++? Я еще не уверен, что . - тоже плохой выбор.

. нельзя использовать без критического изменения. Это было бы двусмысленно на языке.

:: используется в C ++ для пространств имен и в C # для префиксов пространств имен (например, global::System ).

Я думал о быстром обходном пути по этой теме - чтобы решить только простое наследование - склейте файлы pegjs вместе, сохранив все пространство имен.

Это может сделать грамматику слишком многословной и потребует этапа построения, но, глядя на светлую сторону, это заставит вас иметь детализированные грамматики DRY и OTW.

Что касается разметки, не говоря уже о том, что это подходит для этой темы, но это просто вариант, который стоит рассмотреть, я собирался сделать простой__

languages = static__languages / dynamic__languages
<static-languages.pegjs>
<dynamic-languages.pegjs>
/* alternative */
languages = STATIC__languages / DYNAMIC__languages

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

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

@odonnell +1 за выпуск чего-либо - независимо от того, есть ли у вас время, чтобы это очистить

и +1 за разъяснения. Это следует рассматривать как быстрое решение, а не как долгосрочное правильное решение.

@odonnell, мой взгляд на это онлайн на https://github.com/andreineculau/core-pegjs - пожалуйста, ткните меня, если у вас есть что-то получше.

+1 за эту функцию

: +1:

: +1:

: +1:

Я пошел и написал плагин / расширение для PEG.js, которое выполняет импорт: https://github.com/casetext/pegjs-import.

+1 за это тоже.

Я реализую это в # 308 в общем виде: включение грамматики - это только один способ реализовать правила декомпозиции.

Отличная особенность: +1:

С нетерпением жду его выхода.

: +1:

Потрясающий! : +1:

@dmajda Я опаздываю на эту вечеринку, но мне интересно, как часто нам нужно импортировать много правил из другой библиотеки. Я хотел бы иметь возможность импортировать такие вещи, как Url и Email в мои составленные грамматики, но меня не волнует, что Url может также иметь такие вещи, как HierarchicalPart и AsciiLetter . Как вы думаете, будет ли что-то вроде именованного экспорта Node жизнеспособным путем, сохраняющим преимущества пространств имен, но позволяющим прямой именованный импорт?

import { SchemalessUrl, Url } from "./Urls.pegjs"

Token
  = PhoneNumber
  / Url
  / SchemalessUrl

Пространство имен было проблемой для меня, когда я пытаюсь исследовать написание грамматик, которые можно компоновать иначе. Я застрял прямо сейчас, включая файлы в файлы и называя вещи так, как были названы функции PHP до того, как они представили правильные пространства имен: UrlIpHost , HtmlQuotedString и т. Д.

@dmajda @futagoza

Есть ли прогресс по этому вопросу? или первичная дискуссия, живущая сейчас на # 473?
Мой файл грамматики очень быстро растет :(
Было бы неплохо разделить его на несколько

Я бы не прочь разделить грамматику между файлами просто для организации и композиции. Это упростило бы их тестирование и повторное использование, а также, возможно, предоставило бы способ динамической замены грамматик? Просто мысли.

Пример JavaScript, который я использовал в качестве основы, содержит более 1300 строк. Потребовалось время, чтобы узнать, где все было, прыгать и редактировать разные разделы.

@mikeaustin Я рассматриваю эту фичу как своего рода Node.JS required :

кошка bash.pegjs
{
const _ = require ("пробел");
const LB = require ("line_break");
const CodeBlock = require ("code_block");
const BoolExpr = require ("логическое_выражение");
}
...
IfStatement = "if" _ "[" BoolExpr "]" _ ";" _ "тогда" LB? CodeBlock "фи"

Я согласен, разделение грамматик и создание их модульных - отличная функция, однако обработка таких случаев может быть проблемой:
1- подграмматика, которая полагается на глобальную переменную, которая была определена в основном коде грамматики?
2- повторяющиеся переменные и имя грамматики?

ИМО, временным подходом было бы создание нового дополнения для PEG.js (независимо от PEG.js), которое определяет ключевое слово для импорта (например, @load (anotherGrammarFileLocation)), ключевое слово не должно быть частью грамматики javacsript / peg.js,
создать reg-exp или грамматику привязки, чтобы обнаружить это ключевое слово и заменить его содержимым "anotherGrammarFile Location", и отправить замененный код в PEG.js

Пример:

целые числа.pegjs

integers=[0-9]* {return parseInt(text())}

main.pegjs

arrayOfInteger="["(integers ",")* integers"]"
@load("integers.pegjs")

Обратите внимание на использование этого метода, если кто-то не определил начальную грамматику и поместил @load перед "arrayOfInteger", peg.js примет первую грамматику как начало (целочисленная грамматика)

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

Пользователь должен нести ответственность за любое дублирование.

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

Если вам неудобно использовать грамматику длиной в 1 тыс. Строк, разделите ее и соедините обратно, как считаете нужным, прежде чем перекачивать ее в pegjs.