Pegjs: 시맨틱 액션의 약어

흥미로운 아이디어지만 개인적으로 그것이 함수에 전달되는 인수가 명확하지 않기 때문에 더 명확한 방법이 될 것이라고 생각하지 않습니다. 또한 "사용자 정의" 매개변수를 전달해야 하는 경우 일반 함수 호출과 혼합해야 하므로 간단한 경우처럼 깨끗해 보이지 않습니다.

#235의 누군가가 => 구문을 화살표 기능과 함께 제안했는데, 상당히 깔끔하고 간결하다고 생각했습니다.

  = '(' expr:some_expression ')' => expr
  ;

저는 속기 구문에 대해 다음 중 하나를 선택하려고 합니다.

• => expr; _(구문 지원 필요)_
• { => expr } _(지금 사용 가능하지만 포장을 풀어야 함)_
• { > expr } _(구문 지원 필요)_

아직 결정되지 않았으므로 논의를 위해 열려 있습니다.

OP가 원하는 것에 관해서는 Acorn 또는 @babel/parser를 사용하여 식별자 또는 멤버 표현식의 래핑을 풀고 호출 표현식으로 변환하는 플러그인을 구현하는 것이 가장 좋습니다. 레이블을 인수로 사용하고 생성된 코드를 반환합니다.

=> expr;

내 의견으로는 최고.

{ => expr }

Javascript 구문 IMO와 충돌합니다. { } 있으므로 전체 화살표 함수( () => )

{ > expr}

PegJS 또는 Javascript의 다른 구문과 약간 직교하지만 주로 중괄호 안에 있기 때문에 "이는 값을 반환하는 약식" IMO를 즉시 읽지 않습니다. {=> expr} 와 같은 인수 , Javascript가 있을 것으로 예상합니다.

또한 {} 에 non-JS 구문을 추가하는 것은 구문 하이라이터, 린터 등의 문제입니다. 저는 반대합니다.

내가 또 다른 옵션을 제안할 수 있다면 아마도 > 자체(술어 블록 내부가 아님)일 것입니다. 규칙을 세로로 배치할 때 정렬을 유지하는 데 도움이 됩니다.

    = foo:bar qux:(' '+ @qix)+
    > {foo, qux}
    ;

뿐만 아니라 인라인

some_rule = foo:bar qux:(' '+ @qix)+ > {foo, qux};

'=>'에 세미콜론이 필요한 이유는 무엇입니까? 예를 들어 buildList()를 사용하는 대신 중첩 코드에서 값을 반환하고 싶습니다.

  = "(" _ head:Expression _ tail:("," _ expr:Expression => expr)* ")" {
      return [head, ...tail]
    }

매직 인덱스(아래)를 사용하는 것보다 이것이 더 깔끔합니다. 또 다른 옵션은 중첩 레이블을 참조하는 기능입니다. 예: ("," _ tail:Expression)* ")"

  = "(" _ head:Expression _ tail:("," _ Expression)* ")" {
      return buildList(head, tail, 2)
    }

parser.pegjs를 보고 있었는데 434행 주위에 CodeBlock이 있는 것을 보았습니다. 그것을 시도하려면 무엇을해야합니까? 규칙 코드는 단순히 '.'인 SourceCharacter를 읽습니다.

CodeBlock "code block"
  = "=>" __ <strong i="13">@Code</strong> // this?
  / "{" <strong i="14">@Code</strong> "}"

@mikeaustin 네, 맞습니다. 하지만 이 시퀀스를 끝낼 위치를 알 수 있는 방법이 없으므로 => 이후에 모든 것을 소비합니다.

"코드"가 대괄호와 중괄호의 균형을 맞추고 LineTerminator를 처리하는 좀 더 똑똑할 수 있을까요? 전체 JavaScript에 대해 알 필요는 없지만 생각보다 어려울 수 있습니다.

사실, 다음과 같은 변경 사항이 효과가 있을 수 있다고 생각했습니다.

CodeBlock "code block"
  = "=>" _ expession:CallExpression {
       return `return ${ expession };`;
     }
  / "{" <strong i="6">@Code</strong> "}"
  / "{" { error("Unbalanced brace."); }

// Will be based on ECMAScript's CallExpression
CallExpression
  = ...
  / MemberExpression

// Will be based on ECMAScript's MemberExpression
MemberExpression
  = ...
  / ValidIdentifier

// Change `LabelIdentifier` into `ValidIdentifier`

이 방법은 여전히 ​​ECMAScript의 기본 표현식(숫자, 부울, 배열 등)과 같은 일부 항목을 인수로 사용하여 통합해야 하므로 추가할 항목을 신중하게 파악해야 합니다.

균형 브래킷 및 중괄호

이것은 적절한 JavaScript 파서가 PEG.js 파서에 내장될 때까지 수정되지 않을 것이지만, 솔직히 말해서 다른 언어(C, PHP, TypeScript 등), 그리고 언젠가는 파서를 생성할 수 있는 컴퓨터 언어도 작업하고 있습니다.

_PEG.js이 v0.12_ 외에도, 나는에 작업 할 OpenPEG 충분한 기능이 같은 프로젝트를 자바 스크립트 기반 있도록 기본적으로 포함 된 자바 스크립트 파서 발생하지 않고 PEG.js의 버전을 박탈 인 NPM 패키지를 제공 할 것이다,하지만, PEG.js는 백엔드로 사용할 수 있습니다. _v0.12_가 나오면 커스텀 파서를 생성하는 모든 플러그인 프로젝트에 OpenPEG에 대한 알림을 제공하고 v1 이전에 전체 ECMAScript 2015 파서를 PEG.js 문법 파서에 구현하도록 노력하겠습니다.

FWIW, 나는 이것을 위해 템플릿 리터럴을 사용하기 시작했습니다. 또한 내 텍스트 편집기에서 JS의 구문 강조 표시를 하는 데 도움이 됩니다...

exports = module.exports = functionBodies`${grammarScript}
...
objectText =
    head:word
    rest:(_txt_ word)*
    ${f=>{
        return new Txt(rest.reduce((a,b)=>([...a,...b]),[head]))
        }}
word = ch:(wordCharacter/escapedCharacter)+ ${chJoin}
...
`
function functionBodies(glue, ...fns){
    return glue.map( (str,i) => str + (fns[i]||'').toString().replace(/^[^{]*/,'').replace(/[^}]*$/, '') ).join('')
    }

function chJoin(ch){return ch.join('')}

제안된 파이프 연산자(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator)를 사용하는 것은 어떻습니까? 기본적으로 데이터 파이프를 요청하기 때문에?

{
  function extract(value) {
    return value;
  }
  function concat(head, tail) {
    return head ? [head].concat(tail) : [];
  }
  function toAddExpr(head, tail) {
    return { type: 'addExpr', expressions: concat(head, tail) };
  }
}

List
  = '(' _ head:Item? tail:( _ ',' _ value:Item |> extract )* _ ')' |> concat

// Another kind of list
Add
  = '(' _ head:Multiply? tail:( _ '+' _ value:Multiply |> extract  )* _ ')' |> toAddExpr

이런 일이 일어나서는 안 됩니다. 짧은 구문이 없어야 합니다.

화살표를 옆으로 끼우려고 하는 대신 정상적으로 화살표를 구문 분석하는 경우에는 이 중 어느 것도 필요하지 않습니다.

이것은 깔끔한 아이디어이지만 JavaScript에 비해 광범위한 문법 모호성을 설정합니다. JS를 구문 분석하고 with 사태가 무엇인지 기억하는 사람은 이것이 기본적으로 파서를 죽일 것이라는 것을 알고 있습니다.

멋진 새 것을 만들려고 하는 대신 Javascript를 지원해야 합니다. 화살표 함수는 ES6보다 오래된 것이고 ES6은 2015년부터입니다. 이것은 6년 전에 해결되었습니다. 여기서 어떤 발명도 일어나서는 안 됩니다.

파이프 연산자는 심각한 결함이 있으며 아마도 실제로 Javascript로 만들지 못할 것입니다. 파이프 연산자가 원래 파생된 언어(F#)와 이를 대중화한 언어(Elixir)는 모두 이를 거부하고 있습니다. 게다가 이것은 어떤 의미에서 배관이 아닙니다.

PEG가 그렇게 성공적인 이유는 그것이 최소화되고 언어에 가깝기 때문에 빠르고 작으며 예측 가능하기 때문입니다.

화살표 함수는 ES6보다 오래된 것이고 ES6은 2015년부터입니다. 이것은 6년 전에 해결되었습니다. 여기서 어떤 발명도 일어나서는 안 됩니다.

음. 그것은 나에게 새로운 소식이다. 확장할 생각?

PEG가 그렇게 성공적인 이유는 그것이 최소화되고 언어에 가깝기 때문에 빠르고 작으며 예측 가능하기 때문입니다.

PEG(이 라이브러리가 아니라 개념으로)가 성공한 이유는 복잡한 문법(재귀 등)을 단순한 방식으로 표현하는 능력 때문입니다. Packrat은 이 라이브러리로 발명되지 않았습니다. 구문이 아닙니다. 알고리즘입니다.

화살표 함수는 ES6보다 오래된 것이고 ES6은 2015년부터입니다. 이것은 6년 전에 해결되었습니다. 여기서 어떤 발명도 일어나서는 안 됩니다.

음. 그것은 나에게 새로운 소식이다. 확장할 생각?

나는 당신이 무엇을 묻는지 잘 모르겠습니다.

화살표 함수는 ES6보다 오래되었습니다. 이것은 ES6에서 두 번째로 큰 싸움이었고, ES4를 탈선시킨 것과 ES5+를 탈선시킨 것입니다. 90년대 중반부터 모든 사람들이 그 시점에서 E4X에 이미 존재했기 때문에 그것들을 요구해 왔으며, 구글과 애플이 마이크로소프트가 무엇이든 발명한 적이 있다고 Hixie를 비난했기 때문에 제거되었습니다.

이제 E4X를 React로 알고 있고 Facebook이 그것을 발명했다고 생각합니다. 페이스북은 하이퍼스크립트를 도용했다고 생각합니다. Hyperscript 사람은 그가 이전 IE에서 유용한 것을 다시 구현하고 있다는 것이 분명합니다.

템플릿 문자열과 마찬가지로 ES6에서 완전히 제외될 예정이었지만 Coffeescript가 등장하여 JS 커뮤니티에 두 가지를 모두 제공했으며 JS 커뮤니티는 ECMA 사람들이 움직일 때까지 소리쳤습니다. 18개월밖에 걸리지 않았다

화살표 함수는 여기에서 발생하는 모든 작업을 수행합니다. 2018년에 이 스레드에서 문제를 제기한 사람이 바로 당신인 것 같습니다. 나는 당신을 지원하려고했습니다.

나에게 더 중요한 것은 화살표 기능으로 완료되면 아무것도 추가되지 않는다는 것입니다.

JS와 Peg의 차이점은 절대적으로 미미합니다. ES6 작업을 수행하여 이를 지원한다는 것은 목록이 변경되지 않는다는 것을 의미합니다.

그것은 매우 가치 있는 일입니다.

PEG(이 라이브러리가 아니라 개념으로)가 성공한 이유는 복잡한 문법(재귀 등)을 단순한 방식으로 표현하는 능력 때문입니다.

동의하지 않습니다. 많은 파서가 이것에 대해 훨씬 더 잘 수행하며 그들에 대해 아는 사람들(Earley와 같은)에게도 약간 인기가 없습니다.

전통적인 설명은 오류 메시지 품질과 속도의 조합이지만, 많은 파서가 더 나은 오류 메시지를 더 빨리 가지고 있고(Earley와 같이) 사람들 사이에서도 약간 인기가 없기 때문에 저도 동의하지 않습니다. 그들에 대해 아는 사람

또한 PEG에는 세 가지 심각한 복잡성 한계가 있습니다.

첫째, 페그 문법을 통해 입력하려는 모든 항목에는 로컬 시스템의 캐시 및 평가 처리량을 압도하지 않는 조합 표현식이 있어야 합니다(예제 #623).

두 번째, BNF 구문 분석과 같은 많은 일반적인 작업은 종종 peg에서 매우 어렵습니다(예제 #489).

세 번째, 훨씬 더 강력한 모든 다른 JS PEG 라이브러리가 실패했다는 점은 주목할 가치가 있습니다. 나는 여러 번 전환하려고 시도하고 돌아 왔습니다. 특히, c , ruby 및 python 를 추가로 타겟팅할 수 있기 때문에 canopy 로 전환을 여러 번 시도했습니다. javascript

물론 제가 말할 수 있는 것은 이 제품을 사용하고 있는 24명 정도의 사람들뿐입니다. 그리고 나는 할 수 있습니다. 왜냐하면 며칠 전에 새로운 비 유지 관리자가 소프트웨어를 버리고 몇 년 동안 변경 사항이 게시되지 않은 후 처음부터 만든 것으로 교체한다는 것을 깨달았을 때

하지만 그들 모두는 기본 개념적 오버헤드가 많지 않은 파서가 필요하거나 동작이 신뢰할 수 있는 빠르고 작은 무언가가 필요하다고 나에게 말했습니다.

출시되지 않은 0.11은 노드 대 크롬에서 의미 있게 다르게 작동하며 노드는 크롬으로 구성됩니다. 그것에 대해 몇 가지 속성 테스트를 작성해 보십시오. 솔직히 좀 무섭습니다.

.

Packrat은 이 라이브러리로 발명되지 않았습니다. 구문이 아닙니다. 알고리즘입니다.

난 팩랫에 대해 아무 말도 하지 않았어, 친구. 무엇을 수정하려는지 잘 모르겠습니다.

그러나 Packrat 구문 분석은 정렬이 알고리즘이 아닌 것과 같은 이유로 알고리즘이 아닙니다. Packrat 구문 분석은 작업이며 여러 가지 방법이 있습니다.

실제로, 대부분의 소개 Haskell 책은 당신이 3-4개의 다른 packrat 파서를 하게 만듭니다. 왜냐하면 그것들은 모나드에 대한 haskell의 접근 방식의 성능 문제에 정말로 매달릴 수 있는 좋은 방법이기 때문입니다. packrats(즉, 알고리즘 변경)는 더 나은 결과를 산출합니다.

.

그 엄지손가락을 다시 생각하시기 바랍니다. 이 라이브러리는 죽은 지 3년이 되었는데 지금 다시 부활시키고 싶습니다.

라이브러리가 죽은 이유 중 일부는 사람들이 2년 동안 dev에 있던 es() 모듈 기능을 추가하는 것과 같은 간단한 유지 관리를 수행하는 대신 기능을 개발하기 위해 계속 시도하기 때문입니다.

라인을 자르고 손으로 쓴 자바스크립트를 끝에 스테이플링하여 PEG 파서를 수동으로 수정해야 합니다.

별이 빛나는 눈은 잠시 동안 감고 실용적인 기름기 많은 팔꿈치가 시작되어야 합니다. PEG는 사용이 감소하면서 내가 본 유일한 주요 NPM 라이브러리입니다. 합리적인 대안을 알지 못한다는 점을 감안할 때, 그것은 나에게 이상하고 혼란스럽습니다.

지금 당장 기여하고 싶은 버그 수정이 있지만 할 수 없습니다.

1. 0.10 은 dmajda가 떠난 후 게시되지 않았습니다.
2. 0.11 은(는) 3년 동안 발행된 적이 없으며 한 달 전에 발행되지 않을 것이라고 발표되었습니다.
3. 대체 0.12 는 peg가 아니라 다른 사람이 처음부터 다른 프로그래밍 언어로 작성한 것이므로 아무도 볼 수 없습니다.

무례하다는 건 알지만 우리는 이 도서관이 죽어가고 있다는 사실을 직시해야 합니다.

이 라이브러리가 다시 업데이트를 보게 된다면 정상적인 개발 프로세스를 받아들여야 할 때입니다. 2020년입니다. 2017년 이후로 아무것도 보지 못했습니다.

아니요, dev 분기는 계산되지 않습니다. 그리고 0.11 의 품질이 충분하지 않고 10 에서 다시 시작하는 것이 11 수정하는 것보다 훨씬 적은 작업이기 때문에 새 유지 관리자는 많은 문제를 다시 열어야 합니다 10 11