Pegjs: 다른 문법 가져오기/포함

중요한 기능이라는 점에 동의하고 1.0 버전 이후에 하고 싶습니다.

(BTW 나는 당신이 제안한 Python과 같은 구문이 마음에 들지 않습니다. Node.js의 require 와 유사한 것이 JavaScript 프로그래머에게 더 친숙하기 때문에 더 좋을 것입니다. 그러나 이것은 다림질할 수 있는 사소한 것입니다. 나중에 나옵니다.)

패치와 함께 제공된다면 1.0 이전에 포함하는 것을 고려하시겠습니까?

파이썬 구문에 대한 귀하의 의견에 동의합니다.

이 기능에 대해 +1

@ceymard 네, 고려하겠습니다.

기능에 대해 +1 및 require 스타일 포함에 대해 +1

@dmajda @ceymard 이것을 구현하는 방법에 대해 이미 생각이 있습니까? 직장에서 프로젝트에 이것을 필요로 하고 구현하려고 합니다. 문제는 이것이 문법을 여러 파일로 분할하거나 상속과 같은 것에 추가해야 하므로 예를 들어 모든 규칙을 상속한 다음 새 문법의 특정 규칙을 덮어쓸 수 있습니다.

@Dignifiedquire 현재 예를 들어 가장 잘 설명할 수 있는 구문 및 의미 체계에 대해 생각하고 있습니다.

정적 언어.pegjs

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

동적 언어.pegjs

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

모든 언어.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 기본적으로 빌드 단계에서 이 작업을 수행하고 있으므로 다른 사용자가 종속성 트리가 있는 문법에서 유용한 파서를 생성할 무언가를 찾고 있다면(결합된 문법을 구현하는 단일 파서가 생성됨) 내가 가진 것을 정리하고 공개하여 더 영구적인 방법으로 이 문제를 처리하는 방법에 대해 토론할 수 있도록 합니다.

또 다른 사실: 문법 구문에 대한 확장을 주로 설계하여 이 문제에 접근하는 것은 중요한 것을 놓치고 있습니다. 우리 모두가 다른 문법에서 규칙을 가져오고 싶어하는 주된 이유 중 하나(또 다른 이유는 명확성)는 공유하는 구문 분석기를 작성할 필요가 있기 때문입니다. 많은 논리. 따라서 생성된 파서는 구문 분석 시간에 의미 있게 재구성할 수 없지만 하나의 모놀리식 구문 분석기보다는 문법 트리가 파서 트리를 생성하는 것이 중요해 보입니다. 파서 세트가 웹 UI의 일부가 될 때 가장 중요하지만 일반적으로 생성된 코드에서 불필요한 팽창을 피하는 것이 문제가 되지는 않습니다.

@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 과 같은 항목도 있을 수 있다는 점 Url 개의치 않습니다 HierarchicalPart 및 AsciiLetter . Node의 명명된 내보내기와 같은 것이 네임스페이스의 이점을 유지하면서도 직접 명명된 가져오기를 허용하는 실행 가능한 방법이라고 생각하십니까?

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

Token
  = PhoneNumber
  / Url
  / SchemalessUrl

다른 방식으로 구성 가능한 문법을 ​​작성하려고 할 때 네임스페이스가 문제였습니다. 나는 지금 파일에 파일을 포함하고 PHP 함수가 적절한 네임스페이스를 도입하기 전에 명명된 방식으로 이름을 지정하는 데 어려움을 겪고 있습니다. UrlIpHost , HtmlQuotedString 등…

@dmajda @futagoza

이 문제에 진전이 있습니까? 또는 현재 #473에 있는 기본 토론?
내 문법 파일이 매우 빠르게 성장하고 있습니다 :(
여러개로 나눠서 하는게 좋을듯

나는 단순히 조직과 구성을 위해 파일 간에 문법을 분할할 수 있는 것에 신경 쓰지 않을 것입니다. 문법을 동적으로 바꾸는 방법을 제공할 뿐만 아니라 테스트하고 재사용하기가 더 쉬울 것입니다. 그냥 몇 가지 생각.

제가 베이스로 사용한 자바스크립트 예제는 1,300줄 이상입니다. 모든 것이 어디에 있는지 배우고 다른 섹션을 이동하고 편집하는 데 시간이 걸렸습니다.

@mikeaustin 나는 이 기능을 일종의 Node.JS required 로 봅니다.

고양이 bash.pegjs
{
const _ = 요구("공백");
const LB = 요구("line_break");
const CodeBlock = 요구("코드 블록");
const BoolExpr = require("부울 식");
}
...
IfStatement = "만약" _ "[" BoolExpr "]" _ ";" _ "그럼" LB? 코드블록 "fi"

동의합니다. 문법을 분할하고 모듈화하는 것은 훌륭한 기능이지만 이러한 경우를 처리하는 것은 문제가 될 것입니다.
1- 주 문법 코드에 정의된 전역 변수에 의존하는 하위 문법 ?
2- 변수 및 문법 이름이 중복됩니까?

IMO, 일시적으로 편리한 접근 방식은 가져오기를 위한 키워드(예: @load(anotherGrammarFileLocation) )를 정의하는 PEG.js용 새 애드온(PEG.js와 별개)을 만드는 것입니다. 키워드는 javacsript/peg.js 문법의 일부가 아니어야 합니다.
reg-exp 또는 peg 문법을 구축하여 해당 키워드를 감지하고 "anotherGrammarFile Location" 콘텐츠로 대체하고 대체된 코드를 PEG.js로 보냅니다.

예시:

integers.pegjs

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

main.pegjs

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

이 방법을 사용하여 누군가가 시작 문법을 정의하지 않고 @load 를 "arrayOfInteger" 앞에 배치

이를 처리하는 한 가지 방법은 동일한 이름의 파일 이름과 시작 문법을 사용하고 새 애드온이 수동으로 시작 속성을 파일 이름으로 구성하도록 하거나 파일 끝의 모든 내용을 대체하도록 하는 것입니다.

사용자는 모든 복제에 대한 책임을 져야 합니다.

저는 이 문제가 주로 최적화 요청이라는 점을 강조하고 싶습니다. 왜냐하면 합성 가능성/모듈성은 특히 문법의 전체 스펙트럼을 제어할 때 스스로 달성할 수 있는 것이기 때문입니다.

1k 라인 길이의 문법이 마음에 들지 않으면 분할하고 pegjs에 펌핑하기 전에 적절하다고 생각되는 대로 다시 연결하십시오.