Pegjs: 작업 없이 규칙에서 특정 표현식의 일치 결과 반환 허용

그 아이디어를 사랑하십시오! ^ 도 매우 직관적입니다.

이것은 중첩되지 않은 규칙에서도 작동할 수 있습니다.

WhiteSpacedIdentifier = WhiteSpace? identifier:Identifier WhiteSpace {return identifier;}
// becomes
WhiteSpacedIdentifier = WhiteSpace? ^Identifier WhiteSpace?

매우 읽기 쉽습니다! 아마도 다음과 같이 여러 ^ 사용할 수도 있습니다.

a = ^b  c  ^d  e

[b, d] 반환할까요? 말이 되는 것 같습니다.

마찬가지로 명명된 캡처와 혼합하면 ^ 규칙이 무시되므로 의미가 있는 것 같습니다.

x = a ^b foo:c { return foo; }

c만 반환합니다.

오, 그 다중 아이디어는 훌륭합니다. 명명된 캡처와 혼합해야 합니다.
오류.

2016년 7월 5일 화요일 01:07 Graham Wakefield [email protected]
썼다:

매우 읽기 쉽습니다! 아마도 여러 ^를 사용하면 다음과 같이 작동할 것입니다.

에이 = ^BC ^데

[b, d]를 반환하시겠습니까? 말이 되는 것 같습니다.

마찬가지로, 명명된 캡처와 혼합하면 의미가 있는 것 같습니다. ^
규칙은 무시됩니다.

x = ^b foo:c { 리턴 foo; }

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pegjs/pegjs/issues/427#issuecomment -230413015 또는 음소거
스레드
https://github.com/notifications/unsubscribe/ABC26k8v0DIzuWUlkoDZGm2ep10Y5bcMks5qShDAgaJpZM4IkuA9
.

설명된 패턴이 매우 일반적이라는 데 전적으로 동의합니다. 행동 없이 표현할 수 있는 방법이 있다는 것은 의미가 있습니다.

제안된 솔루션( ^ 연산자)에 대해 잘 모르겠습니다. 의미가 즉시 명확하지 않은 특수 문자를 사용하는 것은 항상 문제가 되고 학습 곡선에 추가됩니다. 캐릭터가 다른 목적으로 더 잘 사용될 수도 있습니다. 마지막으로 중요한 것은 구문 분석에 직접적인 영향을 미치지 않는 것을 표현식에 넣는 아이디어가 마음에 들지 않는다는 것입니다. $ 연산자에 대한 인스턴스가 이미 하나 있다고 주장할 수 있으며 저도 동의합니다. 그러나 $ 가 (작은) 실수가 아닌지 확실하지 않습니다. 그렇다면 다시는 만들지 않았으면 합니다.

이에 대해서는 1.0.0 이후에 더 깊이 생각하겠습니다.

생각할 거리가 더 있습니다. ^ 와 레이블이 지정된 표현식이 충돌하기 때문에( @grrrwaaa 는 ^ 무시를 제안합니다), 결과를 표시하는 대신 _ignored_ 표현식을 표시할 수 있습니다. (구문 제안!) 빈 레이블을 제공하여:

WhiteSpacedIdentifier = WhiteSpace? identifier:Identifier WhiteSpace {return identifier;}
// becomes
WhiteSpacedIdentifier = :WhiteSpace? Identifier :WhiteSpace?

거기에는 새로운 구문이 없습니다( : 이미 있음). 의미론에 대한 약간의 확장만 있습니다.

• 빈 레이블 허용(이를 "익명" 표현식이라고 합니까?)
• 비익명 캡처가 하나만 존재하는 경우 표현식 일치 배열을 생성하지 않고 대신 일치하는 항목만 반환합니다.

이 경우 보다 일관성 있는 결과로 반환되어야 하는 표현식이 빈 "레이블"로 표시됩니다. 그건 그렇고, 기존 의미를 깨뜨리지 않는 것입니다. 레이블은 존재하지만 이름이 없습니다. 결과에 대한 액세스를 위해 레이블이 도입되었으므로 이름 없는 레이블이 자동으로 결과가 되는 것은 매우 논리적입니다. 자동 라벨과 구체적인 라벨이 동시에 존재하는 것은 금지됩니다. 자동 레이블이 하나만 있는 경우 이러한 동작이 더 요구되기 때문에 단일 결과가 반환되지만 요소가 하나인 배열은 반환되지 않아야 합니다.

@민군

레이블을 반환하지 않는 이유는 무엇입니까?
start = "{" :expr "}" // return expr
start = "{" label:expr "}" // return label
나는 당신이 무언가에 "라벨"을 붙이면 당신이 그것으로 무언가를 하기를 원한다는 것이 이치에 맞다고 생각합니다(예를 들어 그것을 반환).

반면에 start = ex:expr :expr 와 같은 규칙이 오류를 발생시켜야 하는 이유는 무엇입니까?
아마도 자바 스크립트의 함수의 인수 변수와 유사한 작업을 수행해야합니까? 예를 들어 start = ex:expr :expr 는 [ex, expr] 반환해야 합니다. 작업이 있을 때 레이블이 지정된 & arguments 변수( start = ex:expr :expr { return [ex, arguments[0], ex] } )가 있어야 합니다.

@alanmimms 이 아이디어가 마음에
이름 없는 레이블( :expr )이 ^expr 보다 낫다고 생각합니다.

레이블을 반환하지 않는 이유는 무엇입니까?

@nedzadarek 식에 이름을 지정하면 사소한 표현에서 사용하지 않을 가능성이 더 높기 때문입니다. 적어도 이름은 당신에게 중요합니다. 그렇지 않으면 당신이 그것을주지 않을 것입니다, 정말로? 또한, 명명된 라벨과 명명되지 않은 라벨을 혼합하는 것은 의식적인 행동보다 실수일 가능성이 더 높기 때문에 금지된다면 더 안전할 것입니다. 하나의 이름을 제공한다면 다른 이름을 제공하지 않는 이유는 무엇입니까?

불행히도 @opatut 에서 제공하는 자동 레이블은 문법에 모호함을 만들기 때문에 구현이 불가능하다는 것을 인식할 필요가 있습니다. 기본 예:

start = a :b;// `a` - it is rule reference or label?
a = .;
b = .;

따라서 이를 위해서는 다른 캐릭터를 선택해야 합니다. 현재 ~ , (backslash) , @ , # , % , ^ 중에서 선택할 수 있습니다. , - , | , \ 및 , .

또 다른 솔루션 -- 몇 가지 의사 작업을 소개합니다 -- 반환을 위한 간단한 함수 생성을 위한 바로 가기, 예를 들어 {=>[]} 는 _"시퀀스에서 레이블이 지정된 결과를 수집하고 배열에 반환"을 의미할 수 있습니다. , 및 {=>{}} -- 동일하지만 레이블 이름과 동일한 키를 사용하여 객체를 반환합니다. 그러나 이 동작의 구현은 문법 확장을 필요로 하지 않으며 플러그인에 의해 상당히 실현될 수 있습니다. 플러그인으로 그러한 구현을 하는 것이 더 바람직하다고 말할 수도 있습니다.

start1 = a:'a' b c d:. {=>[]};// returns ['a', <d value>]
start2 = a:'a' b c d:. {=>{}};// returns { a: 'a', d: <d value> }

@민군

표현에 이름을 지정하면 사소한 표현에서 사용하지 않을 가능성이 더 높기 때문입니다. 적어도 이름은 당신에게 중요합니다. 그렇지 않으면 당신이 그것을주지 않을 것입니다, 정말로?

네, 이름이 중요합니다 => 사용하고 싶습니다 => 반품하고 싶습니다.
사소하지 않은 표현의 문제는 무엇입니까?

불행히도 @opatut 에서 제공하는 자동 레이블은 문법에 모호함을 만들기 때문에 구현이 불가능하다는 것을 인식할 필요가 있습니다. 기본 예:

예.
::expression 도 헷갈리는 것 같은데요? @dmajda

#235의 중복으로 폐쇄됨

편집: 이 문제를 참조하는 #235에 대한 OP의 의견에 메모를 추가했습니다.