2
해피/알렉스를 사용하여 파서를 작성 중이며 파싱하는 문법이 전적으로 컨텍스트가 자유롭지 않기 때문에 필자는 미리보기 토큰을 보유해야합니다. Happy documentation는 해피에 가능한 버그?
n : t_1 ... t_n {%^ <expr> }
gdecl : type ident paramList block { FDefn $1 $2 $3 $4 }
| type ident paramList ';' { FDecl $1 $2 $3 }
| typedef type ident ';' {%^ mkTypDef $2 $3 }
| struct ident ';' { StructDecl $2 }
| struct ident '{' fieldList '}' { StructDefn $2 $4 }
를 작성한 스레드 렉서를 사용하는 경우,이는 형태의 규칙을 수행 할 수 있음을 시사한다 하나. 난 그냥 모든 유형의 오류를 만들기되지 않았다 확인하기 위해, mkTypDef = undefined을 떠난
happyReduce_6 = happyMonadReduce 4# 2# happyReduction_6
happyReduction_6 (happy_x_4 `HappyStk`
happy_x_3 `HappyStk`
happy_x_2 `HappyStk`
happy_x_1 `HappyStk`
happyRest) tk
= happyThen (case happyOut21 happy_x_2 of { happy_var_2 ->
case happyOutTok happy_x_3 of { (LocTok _ (TokIdent happy_var_3)) ->
(mkTypDef happy_var_2 happy_var_3)}} tk <-- Error Here
) (\r -> happyReturn (happyIn6 r))
:
Parser.hs:301:47: parse error on input ‘tk’
이 오류를 생성 하스켈 기능은 다음과 같습니다 GHC 다음과 같은 오류를 제공합니다. 정상적인 모나드 작품 ({% <expn> })은 정상적으로 작동합니다. 해피 1.19.4와 GHC 7.8.3을 사용하고 있습니다.
이것은 가능성이있는 버그입니까, 아니면 내가 잘못하고있는 것이 있습니까?
실제로 구문 분석 오류는 유효하지 않은'case ... of {...} tk' 표현식을 끝내는 마지막 두 줄에 실제로 있습니다. 문법 구문이 정확한지는 모르겠지만 확실히 행복하다고 생각합니다. –
오, 좋은 전화, 내 실수. 그러면 버그 보고서를 열어 보겠습니다. –
@ReidBarton 귀하의 의견이 질문을 해결했기 때문에 대답으로 되돌릴 수 있습니까? 그렇지 않으면 대답하지 않은 질문으로 어려움을 겪을 것입니다 ... – sclv